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