[Releasing] rethinking the branching scheme

Oswald Buddenhagen oswald.buddenhagen at digia.com
Thu Feb 20 19:22:30 CET 2014


On Thu, Feb 20, 2014 at 09:24:47AM -0800, Thiago Macieira wrote:
> Em qui 20 fev 2014, às 11:25:33, Oswald Buddenhagen escreveu:
> > On Wed, Feb 19, 2014 at 12:05:15PM -0800, Thiago Macieira wrote:
> > > Em qua 19 fev 2014, às 16:35:05, Ziller Eike escreveu:
> > > > We have to “remember" that sha. A natural way to do that is to have it
> > > > as
> > > > HEAD of a 5.2 branch
> > > 
> > > We have that. It's the old/5.2 branch.
> > > 
> > > Right now, it doesn't exist because the release branch contains[*] it, for
> > > the moment.
> > > 
> > > [*] no, it doesn't. For qtbase, it should be
> > > d7b0581c1c2ef60c08d238dae39298af6904918f.
> > 
> > that's because the release downmerge happened days before the stable
> > downmerge, and given that the downmerge was completed by CI at a more or
> > less random moment, it isn't trivial to do it much better without
> > potentially multiple manual fixups per repo. that's why i said
> > maintaining the old/ branches is a hassle. the approach is Just Wrong.
> 
> That's exactly what you proposed in this thread. I don't think creating the 
> old/5.x branches is a problem. They're not CI checked and we're talking about 
> creating a branch.
> 
ehh, no.
the problem with creating old/ branches is that one has to find the last
sha1 before a downmerge. this would be a non-issue if created a new
branch for every release instead of continuously recycling the same
branches.




More information about the Releasing mailing list