On Sat, Apr 2, 2011 at 3:32 AM, Richard Frith-Macdonald
<address@hidden> wrote:
Almost identical (I didn't have the idea of adding 'alpha').
Concrete example ... about a year ago we released base as stable 1.20.0 branch and development 1.21.0
So, our next release would be base-1.22.0
trunk would become 1.23.0
we do development work and fix bugs in trunk, maybe in the summer we fix an important bug and decide make a release with it
so we backport the fix to the 1.22 branch and make a 1.22.1 bugfix release
later in the year we find another bug worth backporting to the 1.22 branch, and we make a 1.22.2 bugfix release
after a year or more we decide to to a new release with all the new development work, so we copy trunk to a 1.23 branch and make the base-1.23.0 release, incrementing the version number in trunk to 1.24.0
In my opinion, it would be better to always opt on a "stable" release. That is, once a week or every other week backport changes from trunk into stable and release those changes on 5 or 6 month intervals... similar to what Nicola mentioned. I understand this is more work but I believe it's a better solution, as well.
My only problem with the above is how would someone define "important". A certain bug might be a show stopped for someone but irrelevant to another, it all depends on what part of base you rely on the most. I also think we should try to stick with the stable release for as long as possible (I like Nicola's idea of 18 to 24 months, or so).
All releases are 'stable' ... we don't do development releases.
We *might* (but won't necessarily) want to make development snapshots available during the year, but these are not 'releases' and don't get separate version numbers.
We also might (but won't necessarily) want to backport bugfixes to earlier releases, providing support for older releases ... in which case we could release 1.20.2 (the 1.20 branch is currently at 1.20.1) or 1.21.2 etc
I like the idea of trunk being classified as 'alpha'.
We could tag any snapshots we make as 'alpha' , but I'd also like to tag them with the date they were created.
Automating that could be a good option. Changing tagging of snapshots from 'alpha' to 'prerelease' shortly before we are planning to make a new release might also be nice.
Just to add more to the confusion... FLTK names they're snapshot releases based on the current revision: fltk-2.0.x-alpha-r8550.