On Sat, Apr 2, 2011 at 3:32 AM, Richard Frith-Macdonald < [email protected]> 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.
_______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
