Re: Versioning/release policy proposal
Most people seem to agree with this, as well as I. Plus it appears to roughly follow Helge's suggestions (although I admit I'm confused by that still). Anyway, I've added this in slightly edited form to our release policy: http://wiki.gnustep.org/index.php/GNUstep_release_policy On Oct 5, 2006, at 4:28 AM, Richard Frith-Macdonald wrote: This is a proposal for conventions to be adopted for releasing GNUstep packages ... the idea being that something like this could be added to our FAQ and used as a reference for making releases and to some extent guiding what changes we allow into trunk in SVN. I'm CC'ing this to the developer list for information purposes, but I lack the time to respond to comments directly (especially if this gets a lot of flaming etc) other than those from GNUstap maintainers. I'm aware that not everyone can be pleased. but I've made my best attempt to satisfy people, and I'm hoping that Adam, Gregory and Nicola will broadly agree and add any final polish taking any other opinions into account. 1. Release Version Numbering scheme We retain the current major.minor.subminor version numbering scheme for releases and for naming tags in svn. eg. when making a release of version 1.2.3 of package foo the svn tag is foo_1_2_3. This is clear, conventional, and well understood. 2. Library Version Numbering scheme We retain the current link between release versions and library (SONAME) versions ... in that changing the major or minor version number of a release also implies changing the library version number, but changing the subminor number does not. So release 1.2.3 of package foo implies library libfoo.so.1.2 as does release 1.2.4 etc. This provides a clear and simple link between release version and library version while allowing us to make releases without having to change the library version we expect apps to link to. 3. Policy on changing version numbers We change the minor version number (and therefore the library version) when we break backward compatibility . This will mean that most releases we make will only change the subminor number rather than the minor number even where we have added substantial new features. While I realise that this has a problem with public perception being that the project is dead because it never makes 'big' new releases, I think it's better to address the problem with improved publicity of what's in the new release rather than by hoping that a big version number change will do it for us. On the rare occasion where we want a big public change, we would change the major version number (and of course SONAME). 4. Release stability policy We advertise a 'stable' release *every* time we break backward compatibility. Doing this requires making two releases pretty much at the same time and bumping the minor version number for each. Eg. if the last release was 1.3.24 then we release 1.4.0 as 'stable' and 1.5.0 as 'unstable', each with the appropriate change in the SONAME. All releases (if any) in the 1.4 family would be bugfix releases. I suspect the vast majority of people would just use the 'unstable' releases (largely defeating the point of having 'stable' ones), but the overhead of doing a 'stable' release is very low, so I don't see why we shouldn't do it. We can make 'stable' releases be those with even subminor version numbers. 5. Standard release procedure (backward compatible with previous version) a. tag the version for release using the name_major_minor_subminor convention. b. make tarballs and installation packages c. bump the subminor version number in trunk d. put release on ftp site and publicise 5. Standard release procedure (NOT backward compatible with previous version) a. bump the minor version number and SONAME and reset the subminor number to zero b. tag the version for release as 'stable' using the name_major_minor_subminor convention. c. make tarballs and installation packages d. bump the minor version number and SONAME and reset the subminor number to zero e. tag the version for release as 'unstable' using the name_major_minor_subminor convention. f. put releases on ftp site and publicise 6. Bugfix release procedure a. if this is the first bugfix release of a package version, make a branch from the tagged release using the tag name as the branch name eg. if the release was tagged in svn as foo/tags/foo_1_2_0 then the branch is foo/branches/foo_1_2_0 b. apply bugfixes to the branch c. tag the branch as foo_1_2_0-1 d. make tarballs and installation packages e. put on ftp site and publicise NB. we only ever make 'bugfix' releases in 'stable' release families, and these are the only sort of releases we make in those families. 7. Breaking backward compatibility We should continue to strive to avoid this. There are basically two areas to address. First: changes to public ivar layout This is painful ... we must continue to collect such changes together and do them
Fwd: Versioning/release policy proposal
Not sure this got through ... so resending Begin forwarded message: From: Richard Frith-Macdonald Date: 5 October 2006 11:28:37 BDT To: Adam Fedor [EMAIL PROTECTED], Gregory John Casamento [EMAIL PROTECTED], Nicola Pero [EMAIL PROTECTED] Cc: Developer GNUstep gnustep-dev@gnu.org Subject: Versioning/release policy proposal This is a proposal for conventions to be adopted for releasing GNUstep packages ... the idea being that something like this could be added to our FAQ and used as a reference for making releases and to some extent guiding what changes we allow into trunk in SVN. I'm CC'ing this to the developer list for information purposes, but I lack the time to respond to comments directly (especially if this gets a lot of flaming etc) other than those from GNUstap maintainers. I'm aware that not everyone can be pleased. but I've made my best attempt to satisfy people, and I'm hoping that Adam, Gregory and Nicola will broadly agree and add any final polish taking any other opinions into account. 1. Release Version Numbering scheme We retain the current major.minor.subminor version numbering scheme for releases and for naming tags in svn. eg. when making a release of version 1.2.3 of package foo the svn tag is foo_1_2_3. This is clear, conventional, and well understood. 2. Library Version Numbering scheme We retain the current link between release versions and library (SONAME) versions ... in that changing the major or minor version number of a release also implies changing the library version number, but changing the subminor number does not. So release 1.2.3 of package foo implies library libfoo.so.1.2 as does release 1.2.4 etc. This provides a clear and simple link between release version and library version while allowing us to make releases without having to change the library version we expect apps to link to. 3. Policy on changing version numbers We change the minor version number (and therefore the library version) when we break backward compatibility . This will mean that most releases we make will only change the subminor number rather than the minor number even where we have added substantial new features. While I realise that this has a problem with public perception being that the project is dead because it never makes 'big' new releases, I think it's better to address the problem with improved publicity of what's in the new release rather than by hoping that a big version number change will do it for us. On the rare occasion where we want a big public change, we would change the major version number (and of course SONAME). 4. Release stability policy We advertise a 'stable' release *every* time we break backward compatibility. Doing this requires making two releases pretty much at the same time and bumping the minor version number for each. Eg. if the last release was 1.3.24 then we release 1.4.0 as 'stable' and 1.5.0 as 'unstable', each with the appropriate change in the SONAME. All releases (if any) in the 1.4 family would be bugfix releases. I suspect the vast majority of people would just use the 'unstable' releases (largely defeating the point of having 'stable' ones), but the overhead of doing a 'stable' release is very low, so I don't see why we shouldn't do it. We can make 'stable' releases be those with even subminor version numbers. 5. Standard release procedure (backward compatible with previous version) a. tag the version for release using the name_major_minor_subminor convention. b. make tarballs and installation packages c. bump the subminor version number in trunk d. put release on ftp site and publicise 5. Standard release procedure (NOT backward compatible with previous version) a. bump the minor version number and SONAME and reset the subminor number to zero b. tag the version for release as 'stable' using the name_major_minor_subminor convention. c. make tarballs and installation packages d. bump the minor version number and SONAME and reset the subminor number to zero e. tag the version for release as 'unstable' using the name_major_minor_subminor convention. f. put releases on ftp site and publicise 6. Bugfix release procedure a. if this is the first bugfix release of a package version, make a branch from the tagged release using the tag name as the branch name eg. if the release was tagged in svn as foo/tags/foo_1_2_0 then the branch is foo/branches/foo_1_2_0 b. apply bugfixes to the branch c. tag the branch as foo_1_2_0-1 d. make tarballs and installation packages e. put on ftp site and publicise NB. we only ever make 'bugfix' releases in 'stable' release families, and these are the only sort of releases we make in those families. 7. Breaking backward compatibility We should continue to strive to avoid this. There are basically two areas to address. First: changes to public ivar layout This is painful ... we must continue
Re: Fwd: Versioning/release policy proposal
Hi Richard, A clear document, the only thing I miss is a rationale for the use of the SONAME with a major.minor structure, instead of the more common major. I think this would help in the understanding why, and resulting in less discussion. I could even imagine that you use the SONAME major for make and base, while keeping major.minor SONAME for gui/back unit they hit 1.0. Just an idea. Thanks, Dennis Richard Frith-Macdonald wrote: Not sure this got through ... so resending Begin forwarded message: From: Richard Frith-Macdonald Date: 5 October 2006 11:28:37 BDT To: Adam Fedor [EMAIL PROTECTED], Gregory John Casamento [EMAIL PROTECTED], Nicola Pero [EMAIL PROTECTED] Cc: Developer GNUstep gnustep-dev@gnu.org Subject: Versioning/release policy proposal This is a proposal for conventions to be adopted for releasing GNUstep packages ... the idea being that something like this could be added to our FAQ and used as a reference for making releases and to some extent guiding what changes we allow into trunk in SVN. I'm CC'ing this to the developer list for information purposes, but I lack the time to respond to comments directly (especially if this gets a lot of flaming etc) other than those from GNUstap maintainers. I'm aware that not everyone can be pleased. but I've made my best attempt to satisfy people, and I'm hoping that Adam, Gregory and Nicola will broadly agree and add any final polish taking any other opinions into account. 1. Release Version Numbering scheme We retain the current major.minor.subminor version numbering scheme for releases and for naming tags in svn. eg. when making a release of version 1.2.3 of package foo the svn tag is foo_1_2_3. This is clear, conventional, and well understood. 2. Library Version Numbering scheme We retain the current link between release versions and library (SONAME) versions ... in that changing the major or minor version number of a release also implies changing the library version number, but changing the subminor number does not. So release 1.2.3 of package foo implies library libfoo.so.1.2 as does release 1.2.4 etc. This provides a clear and simple link between release version and library version while allowing us to make releases without having to change the library version we expect apps to link to. 3. Policy on changing version numbers We change the minor version number (and therefore the library version) when we break backward compatibility . This will mean that most releases we make will only change the subminor number rather than the minor number even where we have added substantial new features. While I realise that this has a problem with public perception being that the project is dead because it never makes 'big' new releases, I think it's better to address the problem with improved publicity of what's in the new release rather than by hoping that a big version number change will do it for us. On the rare occasion where we want a big public change, we would change the major version number (and of course SONAME). 4. Release stability policy We advertise a 'stable' release *every* time we break backward compatibility. Doing this requires making two releases pretty much at the same time and bumping the minor version number for each. Eg. if the last release was 1.3.24 then we release 1.4.0 as 'stable' and 1.5.0 as 'unstable', each with the appropriate change in the SONAME. All releases (if any) in the 1.4 family would be bugfix releases. I suspect the vast majority of people would just use the 'unstable' releases (largely defeating the point of having 'stable' ones), but the overhead of doing a 'stable' release is very low, so I don't see why we shouldn't do it. We can make 'stable' releases be those with even subminor version numbers. 5. Standard release procedure (backward compatible with previous version) a. tag the version for release using the name_major_minor_subminor convention. b. make tarballs and installation packages c. bump the subminor version number in trunk d. put release on ftp site and publicise 5. Standard release procedure (NOT backward compatible with previous version) a. bump the minor version number and SONAME and reset the subminor number to zero b. tag the version for release as 'stable' using the name_major_minor_subminor convention. c. make tarballs and installation packages d. bump the minor version number and SONAME and reset the subminor number to zero e. tag the version for release as 'unstable' using the name_major_minor_subminor convention. f. put releases on ftp site and publicise 6. Bugfix release procedure a. if this is the first bugfix release of a package version, make a branch from the tagged release using the tag name as the branch name eg. if the release was tagged in svn as foo/tags/foo_1_2_0 then the branch is foo/branches/foo_1_2_0 b. apply bugfixes to the branch c. tag
Re: Versioning/release policy proposal
On 6 Oct 2006, at 12:04, Dennis Leeuw wrote: , the only thing I miss is a rationale for the use of the SONAME with a major.minor structure, instead of the more common major. I think this would help in the understanding why, and resulting in less discussion. I have no real idea of what's more common, but my rationale for this is as follows ... 1. I assume that changing the major version number is primarily a marketing/presentation issue 2. I assume that we *must*, as a technical issue, change the SONAME when we break backward compatibility 3. I assume that our publicity issues and our technical issues will not be in sync ... we most likely won't want to increment the major version number as often as we need to change the SONAME. I could even imagine that you use the SONAME major for make and base, while keeping major.minor SONAME for gui/back unit they hit 1.0. Just an idea. I would prefer to try to keep to a consistent policy across all packages (though for make the SONAME issue is irrelevant as there is no dynamic library in the package), simply because consistency makes it easier to understand and follow. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Fwd: Versioning/release policy proposal
I like this proposal very much, there is one area, where I see problems, but we could wait until we actually face them. This is the question, who will be willing to work on the bugfix releases? Most developers will spend their time and efforts on the new unstable release, then somebody needs to decide that some change to the unstable release is worthwhile to be ported back to the last stable release, integrate it there and make a release. The procedure itself sounds fine, but as long as nobody volunteers to actually follow it, it wont help. Any volunteers? Fred Richard Frith-Macdonald schrieb: 4. Release stability policy We advertise a 'stable' release *every* time we break backward compatibility. Doing this requires making two releases pretty much at the same time and bumping the minor version number for each. Eg. if the last release was 1.3.24 then we release 1.4.0 as 'stable' and 1.5.0 as 'unstable', each with the appropriate change in the SONAME. All releases (if any) in the 1.4 family would be bugfix releases. I suspect the vast majority of people would just use the 'unstable' releases (largely defeating the point of having 'stable' ones), but the overhead of doing a 'stable' release is very low, so I don't see why we shouldn't do it. We can make 'stable' releases be those with even subminor version numbers. 5. Standard release procedure (backward compatible with previous version) a. tag the version for release using the name_major_minor_subminor convention. b. make tarballs and installation packages c. bump the subminor version number in trunk d. put release on ftp site and publicise 5. Standard release procedure (NOT backward compatible with previous version) a. bump the minor version number and SONAME and reset the subminor number to zero b. tag the version for release as 'stable' using the name_major_minor_subminor convention. c. make tarballs and installation packages d. bump the minor version number and SONAME and reset the subminor number to zero e. tag the version for release as 'unstable' using the name_major_minor_subminor convention. f. put releases on ftp site and publicise 6. Bugfix release procedure a. if this is the first bugfix release of a package version, make a branch from the tagged release using the tag name as the branch name eg. if the release was tagged in svn as foo/tags/foo_1_2_0 then the branch is foo/branches/foo_1_2_0 b. apply bugfixes to the branch c. tag the branch as foo_1_2_0-1 d. make tarballs and installation packages e. put on ftp site and publicise NB. we only ever make 'bugfix' releases in 'stable' release families, and these are the only sort of releases we make in those families. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Versioning/release policy proposal
On 6 Oct 2006, at 19:16, Fred Kiefer wrote: I like this proposal very much, there is one area, where I see problems, but we could wait until we actually face them. This is the question, who will be willing to work on the bugfix releases? Most developers will spend their time and efforts on the new unstable release, then somebody needs to decide that some change to the unstable release is worthwhile to be ported back to the last stable release, integrate it there and make a release. The procedure itself sounds fine, but as long as nobody volunteers to actually follow it, it wont help. Any volunteers? Helge claims that people *will* backport fixes from unstable to stable releases. I'm not convinced, but I don't see any reason why we shouldn't try it ... the worst that can happen is that nobody ever backports any bugfixes, in which case we are really in much the same position that we are in now ... the only additional overhead we have incurred is making two releases at once. The ideal situation is to persuade people who don't normally contribute to do the bugfix backporting ... because they are just backporting code that people have already contributed, there is probably no copyright assignment issue, so we could accept *anyone* doing that for us, without having to go through any administrative formalities. That lowers the entry barrier for volunteer and we would just need to review their patches and commit them. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev