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