+1
On 9/28/15 11:20 AM, Till Westmann wrote:
I think that we should aim to never need to pick from master to
release, only from release to master.
The release branch gets all the release fixes and those are merged
into master more or less immediately.
And development continues on master and everybody developing off
master needs to merge the current master (that includes the release
fixes) into their work.
This is at least how I’ve seen this handled in the past or revision
control systems that were much worse at merging that git …
Cheers,
Till
On 28 Sep 2015, at 11:03, Ian Maxon wrote:
Gerrit can totally handle more than one branch. Having a branch in the
ASF repo, likewise, is a near zero overhead operation.
I've had similar thoughts about this, and I know it's not without
precedent, so the idea is definitely +1 from me.
I think the only sticky part could possibly be merge vs. rebase.
Imagine if a change needs to be picked from the master to release
branch, but not some of its predecessor commits. The commit itself
would have to change despite having (likely/hopefully) semantically
equivalent content, and I think that could get very messy (similar
issue to the squashed feature branch discussion).
-Ian
On Mon, Sep 28, 2015 at 9:29 AM, Till Westmann <[email protected]> wrote:
I think that a release-branch sounds like a good idea. The question
is, how
we manage the code/review flow. To be able to review the changes the
should
go into the release in the usual way, I think that we’d need to have
Gerrit
know about more than one branch. Not sure how easy/difficult that
is. Also,
the release branch obviously would need to be in the ASF git repo.
How much effort do you think this would be (infrastructure-wise)?
Cheers,
Till
On 27 Sep 2015, at 23:31, Chris Hillery wrote:
There are a lot of changes that are stacking up in Asterix because
we're
trying to get a release done. I'm thinking it might be a good
exercise and
preparation for next time if we branched Asterix master for the
release
and
started allowing changes to be merged that are for post-release,
instead
of
basically having a code freeze which has been going on for, what,
several
months already?
We could either create a release branch off master and do the
necessary
release cleanup over there, or else create a "develop" branch from
master
and start committing new changes there. Branching a release branch off
master probably would require fewer changes to our existing
infrastructure.
Either way, once the release was complete, we'd merge the branch
back onto
master and continue.
Anyone say yay or nay?
Ceej
