19 Feb
2018
19 Feb
'18
5:24 p.m.
"Fabio M. Di Nitto" <fdinitto(a)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(a)github.com> also writes:
On 2/19/2018 10:43 AM, wferi wrote:
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?
--
Regards,
Feri
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 .