stable1 backporting process
wferi at niif.hu
Mon Feb 19 18:24:32 CET 2018
"Fabio M. Di Nitto" <fdinitto at redhat.com> writes:
> there is a PR open to merge stable1-proposed that will keep running CI
> on each cherry-pick backport for now, and we feel the time is ready to
> cut 1.1, we will just merge that PR at once.
So, this sounds like the point of stable1-proposed is to have CI, but I
can't see why stable1 couldn't be set up the same way. What do I miss?
"Fabio M. Di Nitto" <notifications at github.com> also writes:
> On 2/19/2018 10:43 AM, wferi wrote:
>> I don't really understand the master/stable1/stable1-proposed
>> distinction at the moment, because I can't see anything on master
>> which isn't 1.1 material, so we could pretty much release 1.1
>> straight from master.
> you are right, at the moment master and stable1-* haven´t diverged yet
> but they will in future .
It's getting an interesting question nearing the 1.1 release.
Basically, why complicate history by pretending 1.1 is being developed
in parallel with something else? Surely, there'll be a time when some
breaking change (not suitable for 1.x) will have already been merged
into master and still the need arises to cut a 1.x+1 release. Then we
could branch off stable1 from master right before the breaking change
and start doing parallel development when we're forced to. Till then,
I'd find it perfectly fine to tag new minor releases on the master
branch. Is that an oversimplification?
More information about the Devel