There are well proven methods to achieve this. Assuming that there is a
stable branch where all development is based on (I'll call this the
"base" branch herein) and where the "release" branch is based on, a
possible approach would be:
- the release branch is created and under testing, assume we have some
commits on this branch to change the version number thus it diverged a
bit from "base"
- assume there are already other things added to "base" (new features)
since "release" was created
- a bug is found and fixed in "base" (via a pull request) maybe totally
independent from testing the release
- the developer who fixed the bug tells the release manager to include
this fix into the release branch, this can not happen via a merge from
"base" because that would also add the new features present in "base" to
"release"
- instead the release manager does a cherry-pick of the commit(s) that
where added to "base" as part of the bugfix
- if the cherry-pick does not apply cleanly the bugfix needs to be
backported to the release branch, this can be done by creating a new
branch based on "release" and manually backporting the bugfix commits.
This "hotfix" branch can then be tested and merged with "release"
without merging the new features present in "base"
How complex the cherry-picking and backporting is depends on how
disciplined the developers are in contributing atomic commits and how
"modularized" the codebase is. The above is in general what Rom did in
the past when a release was done. In your analogy the release manager
would be the trapdoor that lets bugfixes through but makes sure that new
features are not added to "release".
Regards
Christian
On 08.08.2017 09:49, Richard Haselgrove wrote:
> The major problem here (in my head at least) is how to treat bugfixes during
> the pre-release / test / full release interval.
> Clearly they need to be in the codebase which is being prepped for release:
> but they also need to be in the core development line which will form the
> basis for the next round of development. And we don't want to allow new
> features to creep into the release branch untested.
> We want a form of trapdoor: bugfixes are applied in two places, features are
> only applied in one.
> In my inexperienced mind, the easiest way to achieve that seems to be to
> bugfix in master, develop in branches. Then tag master for the release, and
> re-allow pulls from branches to master.
> What am I missing?
>
> On Tuesday, 8 August 2017, 8:36, Oliver Bock <oliver.b...@aei.mpg.de>
> wrote:
>
>
> Hi Laurence,
>
> On 07/08/17 23:11 , Laurence Field wrote:
>> On 07/08/17 09:55, Oliver Bock wrote:
>>> As Laurence pointed out: release branches are to stabilize
>>> and fix releases.
>>>
>> This is not what I intended to communicate. When the master (which
>> should be stable) has the required features and been tested, a release
>> is made and a branch version major.minor is created. Any important bug
>> fixes can then be applied (by merging) and released with version
>> major.minor.release. No new features should be applied to that branch.
> I understood and I do agree with your description. This could just be a
> matter of wording here.
>
> There could, however, be a minor difference between my and your
> approach. Do you intend to actually publish the major.minor release
> right after branching off? If that's true than consider this: given that
> master is used for integration it, without further measures (see below),
> might be unstable at the point where the release branch is created due
> to a silently failed integration. Thus I'd create the branch, then first
> make sure it's indeed stable ("stabilize") and only then tag
> major.minor.0 and publish it. After that the release branch is used for
> bug fixes and subsequent major.minor.revision releases only ("fix
> releases"). This is roughly (!) in line with what's done in BOINC right
> now. And yes, of course there are no new features added to that branch.
>
> Alternatively, one could use your way but that would require a stricter
> stability of master. In such a scenario master would have to be frozen
> (no more integration) for a short period before a new release branch is
> created. It would then be thoroughly tested and after that the release
> branch is created and the release build right away. I think that can
> have a negative impact on velocity and requires more coordination
> between people due to the lockdown of master. Thus I'm slightly in favor
> of my approach.
>
> Anyhow, we're already discussing little (yet important) details here and
> we should really be focusing on master first.
>
> Cheers,
> Oliver
>
>
>
>
>
> _______________________________________________
> boinc_dev mailing list
> boinc_dev@ssl.berkeley.edu
> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
>
>
> _______________________________________________
> boinc_dev mailing list
> boinc_dev@ssl.berkeley.edu
> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
_______________________________________________
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
