[chef-dev] Re: Re: Re: Re: releases, github milestones, etc.

[Phil Dibowitz < >]

On 05/01/2015 03:24 PM, Bryan McLellan wrote:
> On Fri, May 1, 2015 at 2:01 PM, Phil Dibowitz 
> <
 
> <mailto:
 >>
>  wrote:
> 
>     While I'm always happy to write RFCs (or PRs against RFCs), I don't 
> think it
>     makes any sense for a non-Chef-employee to write one around
>     release-engineering since (a) only Chef-employees will be doing it
>     (justifiably) for the forseeable future and (b) it has to fit into your 
> guys'
>     workflow and tools.
> 
> 
> Our internal tools are already pretty well reduced to a single line in 
> RFC047.
> I like the perspective of someone on the outside adding context like "as
> someone that isn't you, I like knowing thing"
> 
> https://github.com/chef/chef-rfc/blob/master/rfc047-release-process.md#chef-client-release-process-1

I'm loving this discussion. :)

> I think we just ship off master or near master like Lamont is talking about.
> Let's work that out. But that removes the first part of the process where we
> look for closed things and do anything with them. They're already merged to
> the place that they ship from. Ideally, we don't have to merge anything for
> the release because the Maintainers are doing it periodically (which also 
> lets
> people use that code in the nightly builds)

Yup. And in fact, the other half goes away too - no one needs to tag anything
for any release... it's either in when we do the release or it goes to the
next one. Unless you want the tag to mean "blocking this release" in which
case I think we should be very careful with it - maybe only maintainers
can/should add them or something.

> Yeah I don't like freezing master itself. It's been annoying having our
> release tags out on release branches, but I think that's actually okay if 
> our
> release branches are short dead ends. Which is what I think we're talking
> about. But I'm not sure I want a bunch of branches lying around.

I like where you're going, I have minor changes I'd suggest, because...

> It seems like you're going to have problems with the cherry-pick on that 
> final
> merge, but I'd like those branches to get merged back in so they can "go
> away." Am I missing something about git here? Is there a better way to do 
> that?

Right, so I would instead not cherry pick that way. I'd always cherry-pick
from master INTO the rc instead of the other way around. Master should never
ever get behind. So:

git checkout -b 12.x.y-release master
git tag 12.x.y.rc.0 -a
git push origin 12.x.y.rc.0 && git push origin 12.x.y-release
# build and ship off the 12.x.y.rc.0 tag
# development can continue off master
# regression is found
git co master
# fix thing
git commit -a -m "fix regression"
git co 12.x.y-release
git cherry-pick <hash>
git tag 12.x.y.rc.1 -a
git push origin 12.x.y.rc.1 && git push origin 12-release && git push origin
master
# ready to release final, no new changes
git co 12.x.y-release
git tag 12.x.y -a
# build, release
git checkout master
git merge 12-release


-- 
Phil Dibowitz                             

 
Open Source software and tech docs        Insanity Palace of Metallica
http://www.phildev.net/                   http://www.ipom.com/

"Be who you are and say what you feel, because those who mind don't matter
 and those who matter don't mind."
 - Dr. Seuss

Attachment: signature.asc
Description: OpenPGP digital signature