"Fabio M. Di Nitto" fdinitto@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@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.
https://lists.kronosnet.org/pipermail/devel/2018-January/000049.html
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?