On Sun, Apr 26, 2015 at 7:58 PM, Robert Ramey
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-tp4674686... Sent from the Boost - Dev mailing list archive at Nabble.com.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost