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 < [email protected]> 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.
_______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
