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.

Reply via email to