Re: gnustep-base code freeze

[Nicola Pero]

> I thought at FOSDEM we decided not to do the stable/unstable thing?
> Distributions like Debian will only pick up the stable one, which means
> that we end up with loads of people complaining that feature X doesn't
> work with GNUstep, even though it's been supported for a year in trunk
> and six months in the latest release.

Yes.

I'm not sure what the current release policy is (well, I know for gnustep-make);
I think it changed a few times.  If we're discussing it, I have a bit of time
today and will suggest what I think would be good.  (feel free to disagree; and
I may not have time to follow up on the discussion).

If I can suggest an example of a good release policy, I'd suggest the postgresql
one.  They seem to follow the following policy:

 * all releases are "stable"

 * a new "important" release (binary-incompatible with the previous one) every
   18 months or so (eg, 8.4.0, 9.0.0, etc).

 * each "important" release gets small, bugfix-only, binary-compatible releases
   for many years (eg, 8.4.1, 8.4.2, 8.4.3, etc)

Please note that they don't backport improvements, only bugfixes.  That makes it
much easier to support all these subminor releases.

I think it works really well because:

 * it's easy to understand.

 * if you want new stuff, you get new stuff every year or two.  Obviously, you
   need to upgrade if you are upgrading an existing system because you want new
   stuff.

 * if you have live systems that use an old version, you still get important
   bugfixes for them in a binary-compatible format.

 * it approximately matches the release cycle of the typical Linux distribution.

I'll expand on this last point, which is very important.

Generally speaking, the most efficient way to get things out to GNU/Linux users
of a particular distribution would be to use a release cycle that exactly 
matches
the release cycle of the distribution; that would mean that you feed stuff to 
the
distribution exactly when they are preparing the new release to ship, and you 
don't
feed new stuff when they are not preparing a new release to ship (so you'd clock
your development phases to match their non-preparing-a-release periods).

Because there are so many different distributions that we want to support, that
is not possible; but still, we can try to use a release cycle that approximately
matches the average release cycle of these distributions.

That most likely means a major, binary-incompatible release every X months 
(where
the choice of X is obviously subject to debate) which is fed into their new 
"major"
releases, and binary-compatible minor bugfix releases following that for Y years
(where the choice of Y is obviously subject to debate), which is fed into their
"bugfix/support" package upgrade pipeline.

If our X is too small compared to the average one used by Linux distributions, 
ie,
if we release binary-incompatible stuff too often, then most of these will be
ignored by them - users will be frustrated when they see our website advertising
release 12.0 and their distribution is shipping 10.0 with no way to upgrade to 
12.0.
Or, if distributions choose to try and follow us, users will be forced to 
continuously
upgrade everything, which they'd hate.

If X is too big, ie, if we release binary-incompatible stuff too rarely, then 
we're
missing lots of "upgrade opportunities", since each distribution basically 
gives us
a binary-incompatible upgrade slot every X months, and if we don't use it, we 
lose it.

If our Y is too small, then users will be forced to upgrade just to get 
bugfixes.

If our Y is too long, we'll be doing more work than required.

You'll notice that this line of reasoning pushes it towards the 
postgresql-release
model, where the main problem is picking the right X and Y.  I'd think that X=18
months and Y=5 years would be ideal, but the high Y may mean a lot of work to
support old releases.

Thanks