Re: [boost] 1.58.1 bugfix release necessary?

Subject: Re: [boost] 1.58.1 bugfix release necessary?
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2015-04-26 19:11:51

On Sun, Apr 26, 2015 at 7:58 PM, Robert Ramey <ramey_at_[hidden]> wrote:

> John Maddock-2 wrote
> > On 26/04/2015 14:38, Robert Ramey wrote:
> >> What is would be the difference between creating a bug fix release
> >> presumably
> >> called 1.58.1 and just expediting release 1.59 ?
> >
> > A bugfix release is exactly that - bug fixes only, no new features or
> > new libraries.
>
> If we do that, then we'll have to create a new branch since there's already
> new stuff in master.
> Now we'll have to retest the "bug fix" release. And, we'll have to make
> sure
> that all the
> bug fixes get merged back into the master from from which the next release
> is going to be derived.
>
> Seems to me a lot of work when the same effort could be applied to the next
> release.
>
>
Iff the system currently used to manage master and develop branches can be
reused for
another branch, it could be easier than one might expect.
I don't know how it is implemented currently though (except that there is
some kind of bot doing stuffs depending on branches from submodules).

In the bugfix branch scenario:
There would be a new specific branch for the bugfix version, say
"bugfix/1.58.1" created in the root repository,
then each library author would decide if they have something to put in that
bugfix release.
If yes, they would create the same branch for their library repository (as
they do for develop and master).
For fixes already commited in their develop/master branches, they would
"cherry-pick" commits into the bugfix branch where it's ok to do so,
or just duplicate bugfixes. Otherwise they would do specific bugfix
commitsfor for that specific release (for
example if it's a temporary workaround that will be changed in the
develop/master branch later).
When the release time is ready, the same process to release the master
branch would occur, but using the bugfix/1.58.1 branch
instead.

This is actually a pretty common pattern when using decentralized control
sources (it's more or less how gitflow works),
although most of the time it happen with only one repository, so the work
to allow this way of doing bugfix releases might
be more work if the release tools are not flexible enough (yet).
I don't know if it would be a problem in the case of boost to allow this
but it would be convenient for a lot of users
(including myself and the company I work for).
Because it would mean that there can be stable api release with only
bugfixes, instead of bugfixes releases
with potential additional api-breaking changes.
If library authors are not forced to provide bugfix releases but have a
chance to do it if they want (which is not the case currently)
 and if it's not hard to setup (I don't have a clear idea about that),
it would certainly be a good thing.

> > If we go that route then we already have the beta for 1.58.1: it's
> > called 1.58.0.  So we could allow low risk bugfixes for a limited time,
> > and then go straight to a release candidate.
>
> I'm not sure I understand that.  But one thing we could do is leave the
> beta
> out
> there for testing longer.  Right now we put it out there and ask people to
> try
> to install it and test it.  I understand how they install it, but I'm not
> sure
> how they test it.  We don't have a widely used/promoted procedure for
> testing one's
> release on one's own machine (do we?).
>
> Robert Ramey
>
>
>
> --
> View this message in context:
> http://boost.2283326.n4.nabble.com/1-58-1-bugfix-release-necessary-tp4674686p4674826.html
> Sent from the Boost - Dev mailing list archive at Nabble.com.
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>