gnustep-dev
[Top][All Lists]
Advanced

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

Re: gnustep-base code freeze


From: Stefan Bidi
Subject: Re: gnustep-base code freeze
Date: Fri, 25 Mar 2011 18:29:09 -0500

I absolutely agree we need a good project wide release policy.  I really like what you outlined below, but does it fit with the way GNUstep does things?

On Thu, Mar 24, 2011 at 7:21 AM, Nicola Pero <address@hidden> wrote:
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).

So major and minor releases are abi-incompatible... I'm all for that, but then what's the point of that void * at the end of every class?  Personally, I don't like it after working on the 2 formatter classes.

When would GNUstep every have a major number bump?  The way I understand it now, never.  It than begs the question, but does the major number mean to GNUstep?  Obviously GUI and Back have no yet reached 1.0 status, so I can see that, but after it does reach 1.0 status, when will base and gui be bumped to 2.0, 3.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)

I really like this idea (very, very much actually), but does GNUstep plan on concurrently supporting multiple version?  I assume postgresql, like FreeBSD, has at least 2 different "stable" branches (in the fbsd's case you have the 8.2-release and 7.4-release) at any given time.  I really like the idea, but is it feasible with the amount of work something like this would create?

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 assume only the latest version would be advertised to the public.  Equivalent to postgresql only advertising 9.0.x on they're front page but still having 8.4.x available for whoever want it.  Is that right?  Would we advertise the same one to packages?  If so, why would anyone care about the previous stable branch (postresql's 8.4.x)?

Like I said, I really like what you outlined here, just wondering if it'll actually work and GNUstep will stick to it--the release policy has changed at least twice since I've been following the project.


reply via email to

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