|
| From: | Richard Frith-Macdonald |
| Subject: | Re: gnustep release numbers |
| Date: | Wed, 4 Oct 2006 23:12:55 +0100 |
On 4 Oct 2006, at 20:28, Helge Hess wrote:
On Oct 4, 2006, at 18:42, Richard Frith-Macdonald wrote:Note: by 'unstable' I don't mean that the code itself is buggy but that the ABI is unstable.Fair enough ... that's your definition ... but it's rather an unusual one.Really? I think thats the term usually used by OpenSource projects. But anyway ;-)Stability is an inherent requirement for Linux distributions because they can't change the ABI constantly. Which makes it a cycle of ~2 years for all (serious) distributions. But at least 12 months.
Stability for a distribution is simple ... just don't update any of the packages you use for a while.
In fact not all GNUstep releases change the ABI,See my other mail. According to the changelog all the late GNUstep releases always changed the ABI.
You must be reading a different changelog ... anyway this is very silly, I already said that the vast majority of releases add to the ABI ... so the issue of whether you can defend the use of the word 'all' seems rather pointless.
but the ones which you term 'stable' are what are generally called bugfix releases.Yes, 'stable' is the branch. And individual release after the first release of the stable branch is a bugfix release.
So GNUstep releases are now 'stable' because each release starts a branch in svn where bugfixes can be applied ... this is a purely academic distinction from our older convention where we tagged a release and could, if we wanted to appply bugfixes, go back and create the branch from that tagged point later. In either case the releaseprovides a well defined point we can use to add bugfixes in a branch and make bugfix releases.
There are very few of those in GNUstep ... not because there are no bugs, but because we generally lack the manpower (volunteers with the inclination to do it) to make lots of bugfix releases.I honestly don't think that this is a major issue. Those people who need a stable release and have issues with a certain bug will backport fixes (not trunk developers).
Most likely this doesn't need to happen very often because gnustep- make and gnustep-base code is in fact largely bug free. The changes in those libraries are additions/fixups to the API, code improvements/rewrites, performance updates, etc.
Don't forget MacOS-X additions to (and removals from) the API.
And of course the interest in providing bugfix releases to a stable branch increases as the number of stable branches is reduced. Leading to solid software :-)However, it should be easy to tell a bugfix ('stable') release ... it has the same major and minor version number as a normal release, but an incremented subminor number.Yes. But prior having bugfix releases we need a stable branch. One which doesn't change ABI every 3 months but lasts for at least a year, better two. We don't have that.
That's just plain wrong ... we had complaints about too few (ABI compatibility changing) releases and have tried to speed up the release cycle. For base, the latest is five and a half months and the one before that was nearly 8 months, so changing the ABI 'every 3 months' is just a silly exaggeration. Likewise, the idea of two years between releases would annoy a large number of people and is therefore not reasonable.
I accept that you could reasonably argue for a 1 year cycle, but I think the current rate of release is probably about right for most people, and a lot of people would be very glad to see a regular six monthly release schedule with bugfix releases every month or two (if only someone would like to backport fixes from trunk and make bugfix releases),
| [Prev in Thread] | Current Thread | [Next in Thread] |