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

[Thom May < >]

On Sat, May 2, 2015 at 6:17 PM, Phil Dibowitz < " target="_blank"> > wrote:

On 05/02/2015 08:18 AM, Lamont Granquist wrote:
> On 5/1/15 4:11 PM, Phil Dibowitz wrote:
>>> 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.
>>
>>
> I think the person doing the release needs to do the decision as to if its
> blocking or not.
>
> In the future this hopefully goes away, we just pick a nightly to promote.  In
> the present, I think the person doing the work needs to be the decider.  Once
> they're satisfied with what is going into the release, the unfinished stuff in
> the milestone are bumped and the rc branch is cut.
>
> That keeps it so that we don't have maintainers expecting to be able to hold
> up releases for pet fixes that aren't done yet.

I'm fine with that if ChefCo doesn't need to track things think "have" to be
in the next release.

So... what needs to happen to start doing releases off of master?

 

12.3 came off master. (well, I cut a 12.3 branch off master and released from there,

 but that's just noise, frankly. Getting the versions right and tagging master is equivalent).

There's no reason right now for 12.4 not to come off master in a couple of weeks time. 

What we do need to figure out is what Dan mentioned - feature flags to manage

changes that would constitute major versions. 

-Thom