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

[Adam Jacob < >]

I think it's important that you always ship master, as a go forward rule. You don't cherry pick. It's the only way to make sure everyones head is in the stability game, so to speak. Otherwise, we can push complexity into the process rather than the individuals understanding the impact of changes.

Adam

On Wed, May 6, 2015 at 12:08 AM, Phil Dibowitz < " target="_blank"> > wrote:

On 05/05/2015 01:00 PM, Lamont Granquist wrote:
>
>
> On 05/05/2015 09:27 AM, Phil Dibowitz wrote:
>> Can we define "blessing a nightly" - there's sorta two schools of thought here.
>>
>> The first is that nightlies are versioned as such "12.3+nightly20150501" or
>> whatever, and when you want to "bless" a nightly you do a build of the same
>> git hash, but with a version number (12.4).
>>
>> The second is that every nightly has it's own real big-boy version number like
>> 12.46, 12.47 (or better yet 12.20150501, 12.20150502), and then we just update
>> metadata somewhere that says one is blessed which causes it to show up in a
>> different dropdown menu.
> Yeah that's getting at the root problem.
>
> The way I've understood "blessing a nightly" is that literally the artifact is
> copied over into the stable channel and there's no rebuilding or bumping of
> version numbers going on.
>
> If we rebuild and reversion then it makes a bit more sense, then 12.3.97
> becomes 12.4.0 or something like that on release.  However, if we want to make
> a stable release off of 12.3.97 (friday's build) when we've already cut
> 12.3.98 and 12.3.99 (saturday and sunday with some stuff committed over the
> weekend we don't really want to consider 'stable') we need to update the
> version number in lib/chef/version.rb which means a commit off a branch
> starting at 12.3.97 and shipping that instead of shipping the release off
> master.  If we say you can only promo the latest then you've got precisely 24
> hours to decide if the nightly is 'stable' enough for stable or not, which
> seems like a tight timeframe...

I don't think I would say you can only promote the latest nightly. I think
that's being a bit too rigid. I think it makes total sense to give a build
several days to bake before promoting it. I think there should be a cut-off
though. Say, you can't promote something older than a week or whatever.

There just needs to be a clearly defined process. For example, 12.3.57 get's
suggested as the next release Monday, if no one complains by Wed, we cut a
branch on it's hash, and build 12.4.0~rc1 (promoting), and then if there's no
blockers filed within a day or two, we release as 12.4.0. We should have a few
guidelines, like, for example:

* If a major change is going to be required to make an RC releasable, we throw
it away, let that major change get merged into master, and start over with a
nightly
* If blockers are filed against a suggested nightly before an RC is cut, that
nightly is out and we fix open bugs and pick a new nightly

Another approach/idea (not necessarily incompatible with the above) is to
follow the Linus approach: new features can be merged to master until an RC is
cut, and we expect to go through 4-5RCs until we're ready to release, but no
features are merged during the RC process, only fixes. The moment the final
build is released, master is open to new features. Every single release is
always built off of master directly. Master is essentially "locked" only for a
few weeks at a time.

--
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