Taken literally, though, that means we just ship nightlies and version numbers are something like 12.<build>.0 where build increments every day/build and there's no notion of 'stable' branch.
From talking to release engineering I've always understood there would be a 'stable' channel in addition to nightlies, and I'm trying to get at understanding how that should work and what the versions are expected to look like. Not having a stable channel is an option, but this is the first time I've heard it mentioned.
On 05/06/2015 08:53 AM, Adam Jacob wrote:
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
Phil Dibowitz " target="_blank"> <mailto: " target="_blank"> >On Wed, May 6, 2015 at 12:08 AM, Phil Dibowitz < " target="_blank"> <mailto: " 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.
--
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
Archive powered by MHonArc 2.6.16.