From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2008-06-30 11:15:59
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_at_[hidden]> 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk