[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnustep release numbers
From: |
Helge Hess |
Subject: |
Re: gnustep release numbers |
Date: |
Thu, 5 Oct 2006 13:20:42 +0200 |
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
sonames.
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.
Greets,
Helge
--
Helge Hess
http://docs.opengroupware.org/Members/helge/
- Re: gnustep release numbers, (continued)
- Re: gnustep release numbers, Richard Frith-Macdonald, 2006/10/04
- Re: gnustep release numbers, Helge Hess, 2006/10/04
- Re: gnustep release numbers, Hubert Chan, 2006/10/04
- Re: gnustep release numbers, Richard Frith-Macdonald, 2006/10/04
- Re: gnustep release numbers, Hubert Chan, 2006/10/04
- Re: gnustep release numbers, Helge Hess, 2006/10/04
- Re: gnustep release numbers, Jeremy Bettis, 2006/10/04
- Re: gnustep release numbers, Helge Hess, 2006/10/04
- Re: gnustep release numbers, Hubert Chan, 2006/10/04
- Re: gnustep release numbers, Richard Frith-Macdonald, 2006/10/05
- Re: gnustep release numbers,
Helge Hess <=
- Re: gnustep release numbers, Dennis Leeuw, 2006/10/05
- Re: gnustep release numbers, Helge Hess, 2006/10/05
- Re: gnustep release numbers, Dennis Leeuw, 2006/10/05
- Re: gnustep release numbers, Philippe C.D. Robert, 2006/10/29
- Re: gnustep release numbers, Richard Frith-Macdonald, 2006/10/05
- Re: gnustep release numbers, Richard Frith-Macdonald, 2006/10/04
- Re: gnustep release numbers, Helge Hess, 2006/10/04
Re: gnustep release numbers, David Ayers, 2006/10/04