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