[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnustep release numbers

From: Dennis Leeuw
Subject: Re: gnustep release numbers
Date: Thu, 05 Oct 2006 16:01:14 +0200
User-agent: Debian Thunderbird 1.0.2 (X11/20060830)

To quote my own documentation at

The so-name versioning system is described almost everywhere as:

Versioning convention says we have three release numbers:

   1. major release number
   2. minor release number
   3. micro release number

Micro release changes may: improve performance, scalability or some other qualitative property, or fix a bug that does not change the API nor the ABI. Which means no application built against the old version should stop functioning with the new version, but also the otherway around: applications built against the new version should work with the old library. No functionality can be added to a micro release change.

Minor release number changes should be ABI comptible, but can enhance functionality. This means that applications built against the old API will work, but applications built against the new API might not work with the old ABI (hence they depend on the new minor number).

Major release changes will break ABI and API compatibility and thus require a complete rebuild of everything that depends on the libraries.

And as far as I can tell this is exactly why is being done with the GNUstep versioning system.

This of course has nothing to do with "stable" and "unstable" releases. SVN and the daily snapshots are the "unstable" releases, and the numbered releases are stable ones.

Currently the frequency in which we jump Major release numbers, and thus breaking the ABI are not frequent.

Minor releases is open for discussion, depending on your definition of frequent.

And Micro should be frequent.

The discussion is about the Minor part, so let's concentrate on that one. For a maintainer the choices are quite simple, IMO:

1) There is an app that needs the additional functionality, so you have to accept to also supply a library upgrade. Nothing more, so no other applications need to be upgraded.

2) No app needs the additional functionality... you do not have to do anything

Am I missing a point here?

With kind regards,

Dennis Leeuw

Helge Hess wrote:
On Oct 5, 2006, at 07:31, Richard Frith-Macdonald wrote:

If I seem incredibly slow in understanding what you mean by 'stable',

Sorry, seems I can't really explain stuff in a compatible way? ;-)

Well, its actually not "my understanding of stable" but the requirements enforced by soname versioning? I'm actually not sure why there is a discussion on what a stable ABI / soname is because its clearly defined and documented.

Its also kind of obvious that you are not supposed to have 10 different soname versions on a working system but just two or three :-)

please understand that it's just that the idea of trying to enforce a frozen ABI for years seems utterly impractical.

Why? Its basically just that
a) we tag one branch as, say GNUstep 1.2.0, the stable one. we announce this
   on the website and maintain soname stability requirements
b) development continues as-is in trunk with alpha releases (GS 1.3). In fact
   you can do many more releases because you are not expected to  maintain

BTW: please stop exaggerating ;-) I said "2 years" not "for years" and also "at least 1 year" :-) Thats about the devcycle of Linux distries for endusers. It also doesn't need to be completely fixed on a time. Eg if we have a *major* leap in functionality (say KVO is implemented in base or Windows support gets perfect or so), we can do a new stable release. But I don't expect this to happen a lot :-) Development is more the incremental way.

I suppose a 12 month cycle should be reasonable, we would need to see whether we really have enough new features after 12 months :-)

The thing which is utterly impractical is requiring thousands of users to update every few months and having to preserve ten binary releases on the system because they might want to install an old tool/ daemon.

Even for gnustep-base it would not be easy (the drive to MacOS-X compatibility is too strong),

I completely disagree.

If we tag gnustep-base 1.2.0 as stable and this doesn't include, say "NSOutputStream". Now I decide for OGo that we will use this class because its in OSX and its neat and whatever. What you do in this case is a backport, that is you take the class out of trunk, refit it to the stable version and include _just that class_ in your application. That happens all the day with Linux distris. If something is important to have, you get backports for stable distries.

Of course one has to decide whether a backport is worth the effort (do I really want to use NSOutputStream if its not in gnustep stable? how difficult is it to refit the new class to the "old" base?). But its always less effort than upgrading the _very basis_ for a deployment of out-of-the-house developers.

Having a few stops very likely improves the quality in various other areas as well. Eg you finally have _one_ version to document properly (no moving target). Even its quirks, bugs, and workarounds for that (with the alpha ones you always get new quirks and bugs and workarounds ;-). Stuff like that is much more important (even for new users) than having the latest Cocoa class which you won't manage _anyways_ (you are always behind and can't fully please the mythical Cocoa user).

but for other less complete parts of the system and the system as a whole there is really no chance of such a freeze.

I absolutely agree with this one. Its probably impractical for something like gui which is really in alpha state (implementation probably changes quite often).
But I can't really decide on this one.

We would probably have to make the subversion repository private to prevent 'unstable' versions getting out.

Since I don't believe that committers are evil I don't think we need to close down anything :-)

In fact I would volunteer as the release manager for stable versions. That is, checking whether the 1.2 branch is in fact soname compatible with the latest release of that branch, applying bugfixes etc. Before eg Adam makes an release announcement of a new stable version.
I don't expect many stable [bugfix] versions though ;-)

As mentioned 1.3 development could continue at full speed and release 1.3.1, 1.3.2, 1.3.45 ;-) etc version.
Eg in SOPE unstable we have 4.5.9 and OGo I think 1.1.7.

  I think such a freeze would kill GNUstep.

Yes, freezing repositories doesn't really help. But freezing an ABI / a version is very good for all people who just want to use the library. And by this I don't mean endusers but developers which want to develop ObjC on Linux/BSD/Windows.

As mentioned I think that a LOT of people will be using alpha releases to get the latest and greatest. As mentioned before for OGo I guess this is about 50/50 in the user base. Notably the "stable 50" or often newbies which first need to get into the system w/o being exposed to update issues and other sideeffects they do not care about when getting it up and running. The stable OGo (1.0) packages are very well tested and all install-issues are well known and well supported by the community.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]