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!
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.
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.
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. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail