On Mon, Jun 30, 2008 at 11:15 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
Dean Michael Berris wrote:
Sorry to jump in here... Not being a Boost author myself makes this a little awkward, but I'd like to get my $0.02 worth in there.
Commentary by developers who deal with software releases of any form is very much welcome in these!
Thanks. :)
On Mon, Jun 30, 2008 at 11:20 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
David Abrahams wrote:
James Sharpe wrote:
I think the diversion here comes from the fact that only authors (or maintainers) are able to check in code to the subversion repository -- and patches that go towards a 'bugfix point release' need to go through the authors/maintainers. This is a problem of the 'not-always-stable' trunk paradigm, where major/minor development happens on the trunk which gets tested day by day.
Hm, I don't see how that follows. I can see the bottleneck authors time is, and is one of my main points. But I don't see how that follows to the problem of 'not-always-stable' trunk method.
The problem the not-always-stable trunk method brings in this situation is where a fix that has to be made/applied to a library that's already been released either goes first into trunk (because trunk is not intended to be stable at all) then needs to wait for the next release. Since the trunk is not always stable, you then encounter the problem of having to maintain a different version of the libraries in different branches -- a release 1.35, 1.34, 1.35.1, 1.36, etc. -- In case the trunk was always stable, then fixes that get applied to a bugfix release can be merged into the trunk; then further development of the library can happen in a private branch. The unstable trunk also disallows the release manager(s) from simply cutting a branch from trunk every-time a new release is to be made. This exacerbates the problem because now instead of fixes that go into the trunk that's intended to fix an issue in the release branch _for the sole purpose of fixing bugs in that release branch_ will have to be manually merged into the new release branch that was rooted on the previous release version of the library. So now you're faced with two issues: 1. The 'time-to-market' or 'time-to-release' of a fix that's intended to address an issue in a release version gets longer and gets packaged into a new major release. 2. The many versions of the library in supported major release version and the many bug fixes that need to be tracked accordingly. I'm not suggesting that we should start following the 'always-stable-trunk' method -- where we have a private branch named 'unstable' on which all breaking changes on a daily basis happen, and on to which major changes in libraries have to be merged into before being merged into the trunk after full regression testing. I'm rather citing the difficulty of having authors working on private branches then having to merge directly to trunk, and the release managers having to cut branches from the last stable release instead of a stable trunk and merging changes from the trunk done manually.
Not having the name right is a problem: say for example I as a user of the library would like to contribute a patch to a release version that addresses a particular bug *in that release*. Not knowing from which subversion branch to diff from or create a patch from *is* an issue. For example, when 1.36 comes out and we're still supporting the 1.35 release, how do I patch the 1.35 release to create a 1.35.1 release and so on for particular libraries in that release?
Sure, but those are issues of convention only. The name itself is not important, just that we decide on a name. But deciding on a name is the least important aspect. The only option users have at this time is to diff from the tags/release/Boost_x_y_z (or from the archives directly).
So how then would a 1.35.1 release team continue to patch things up in 1.35.0 if the release branch for that release isn't named release_1_35_0?
It could be named release_1_35, or release/Boost_1_35, etc. Hence the name is not important, just that it's agreed upon.
Okay. I guess then we just have to make that convention more 'formal' then?
What is the process of creating a release team for a bugfix release on a major release?
I would think the same as it is now for a regular release. Someone volunteers to be the release manager. And they ask for volunteers to help in the release, assuming they need help. And then they go through the same release process as for a regular release, just on a different branch and schedule.
Okay. -- Dean Michael C. Berris Software Engineer, Friendster, Inc.