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),
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
