Proposal: Mandatory periodic releases
All,One of the ways I've noticed that other projects act is that they, under normal circumstances, try to make regular releases of the code at predictable intervals. This helps to reassure people that the project is active and it also helps to focus developers on impending releases.I'm wondering if this might not be a good thing to start in this project, since our releases tend to be occasional. Just a thought. :) Later,Gregory John Casamento-- Principal Consultant, Open Logic Corp. (A MD Corp.)## Maintainer of Gorm(IB) & GUI(AppKit) for GNUstep.___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal: Mandatory periodic releases
On 2006-03-04 15:57:03 -0700 Helge Hess <[EMAIL PROTECTED]> wrote: More frequent because it will be easier to try out new features (and have a less moving target even for developers) and less frequent because the GNUstep API is too instable for distribution inclusion and to base binary software packages upon. (and ABI change in the core library every 6 months or so is FAR to much, 12 months might be OK, 24 considered stable). Well, I try to do something like this, only I aim for binary compatibility, rather than API stability. That's way too hard for me to track - something that all the developers would have to sign up to do, not just me. The last binary incompatible release was September, last year (7 months). anyway, I try for a release every month or two, although lately it's been three months. Maybe I should just set up an alarm to ping myself every month so I don't get busy and forget. It's not hard to make a release, but it's not trivial either, particularly since I can't possibly test it on all the major systems I'd like to test it on. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal: Mandatory periodic releases
On 7. Mrz 2006, at 16:41 Uhr, Adam Fedor wrote: Well, I try to do something like this, only I aim for binary compatibility, rather than API stability. That's way too hard for me to track - something that all the developers would have to sign up to do, not just me. The last binary incompatible release was September, last year (7 months). I'm not entirely sure what you mean by that. Ensuring ABI/API stability just implies that every once in a while a new version is branched. This branch then is only allowed to add fixes, no new API/ ABI stuff. "Development" of course will continue as usual (with breaking things ;-) in the trunk and with alpha releases. Technically patches (aka bugfixes) to the branch could/should only be allowed for a release manager, could be you or someone else. A patch would need to ensure that nothing ABI/API is changed, this should be reasonably easy. Since a stable release should happen max every 12 months this should be no big burden. And interest to provide fixes when necessary should be high because only stable versions (and API/ABI compatible fixes) are usually allowed in distributions. Summary: IMHO this should be easy with Subversion. Just do a copy of trunk every 12/18/24 months and mark that the stable release and disallow changes. This might imply that this only makes sense for core components like gstep-make and gstep-base since maybe gstep-gui has so many bugs that it doesn't make sense to tag a stable. Can't decide that. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal: Mandatory periodic releases
Hi, On 1. Mrz 2006, at 15:15 Uhr, Gregory John Casamento wrote: One of the ways I've noticed that other projects act is that they, under normal circumstances, try to make regular releases of the code at predictable intervals. This helps to reassure people that the project is active and it also helps to focus developers on impending releases. I'm wondering if this might not be a good thing to start in this project, since our releases tend to be occasional. Just a thought. :) personally I would like to see a split between stable releases and development releases. I talked about that with Nicola at FOSDEM and the impression is that GNUstep lacks both, more frequent AND less frequent releases. More frequent because it will be easier to try out new features (and have a less moving target even for developers) and less frequent because the GNUstep API is too instable for distribution inclusion and to base binary software packages upon. (and ABI change in the core library every 6 months or so is FAR to much, 12 months might be OK, 24 considered stable). In SOPE/OGo we do this by using the Linux version numbering, that is, we have stable releases which are even numbered and NEVER change the API (no additional methods, no additional classes, only fixes). And we have odd numbers which are alpha releases and are allowed to break the ABI. Eg SOPE 4.4.0 is a stable release and 4.4 will never change the ABI while 4.5.1, 4.5.2, ... 4.5.6 are unstable releases and have no soname ABI guarantee. How do we do that in Subversion? If we release a stable version, we copy the trunk tree to a branch, eg: svn cp /trunk /branches/4.4 The trunk then becames the next unstable. Trunk always has an odd numbers and you never have an odd number in (release) branches. To make a stable release, we copy the branch to a release, eg: svn cp /branches/4.4 /releases/4.4.0 To make an unstable release we just copy the trunk, eg svn cp /trunk /releases/4.5.7 BTW: beta releases are also supposed to be ABI stable to the final release. So the first branch is actually a beta, not a final release. I would like to suggest something similiar for GNUstep (at least base ;-). With Subversion this is reasonably easy to do. Keeping ABI stability of course requires A LOT of discipline. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
