asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Maxon <ima...@uci.edu>
Subject Re: Release branch policy
Date Thu, 19 Nov 2015 02:11:16 GMT
Heya Ildar,

1) The person responsible for the merge is whoever made the branch...
so the release manager. It's probably going to be more of a team
effort this time though, because the changes are not just tweaks to
licenses and so on, they're fixes for critical bugs.
2) A release branch should get made every time we make a release so
changes that are specific to the release itself can be done without
holding up new features coming on to master.
3) That's not something that should be done ;) If something belongs on
the release branch, it should really go there first. Cherry picking
won't work because it rewrites the commit. You'll end up having 2
copies of a commit that are semantically equivalent but not equivalent
int git's eyes.


-Ian


On Wed, Nov 18, 2015 at 5:36 PM, Ildar Absalyamov
<ildar.absalyamov@gmail.com> wrote:
> Hi All,
>
> The concept of release branches introduced to unfreeze master while release process is
happening seems to have several issues, which are not clear for me.
> Both me and Yingyi have similar changes, but his are committed to master, whereas mine
will go to release-0.8.8.
> Those conflicts would be reconciled when the release branch is merged back to master,
however this leads to several questions:
> 1. In general case who will be responsible for that merge?
> 2. How do we generally decide when to make a release branch?
> 3. Suppose the release branch was created  at point ABC and possibly bug fixes\features
were submitted to it, but not to master. How would we handle situation when some time later
we decide that feature XYZ from master should also be a part of release. Merge master into
release branch (merging also whatever happened in between ABC and XYZ)? Cherry-pick specific
commit from master?
>
> Best regards,
> Ildar
>

Mime
View raw message