>> Regarding the announcement, let's hold off until Dec.
>> 1st.  That will
>> allow me to finish the GIT migration and actually get the
>> new version
>> number into the code repository.
>
> Sounds good. No rush, plenty of time yet. Save the proposed announcment
> and edit to taste. :)
>
> Probably a good idea to have at least one other person besides you make a
> run at building packages from GIT using the new version number. Basic
> quality assurance. :)
>
> I don't think we agreed on versions for bug fixes and security patches.
>
> Proposal:
>
> I don't want to see the version number increment by one whole number every
> release --- like the joke that Mozilla uses for Firefox. People are likely
> to presume we are doing that simply to create big version numbers, which
> fools nobody and impresses nobody.
>
> For example, the next version in May 2012 will be R14.0. If there is a
> security patch or serious bug fix before the next official release, then
> use the alphabet to bump the version: R14.0a. If the next official release
> introduces nothing major with respect to development, then the next
> release thereafter would be R14.1.
>
> Darrell

This is the approach I was considering.  I also though this was at least
discussed during the meeting, but it is possible that no decision was
reached.

Basically the numbering would be:
R <ABI version> . <bugfix version> . <security patch version>

By definition no major improvements would imply any changes are bugfixes,
so it should work as intended. :-)

Tim