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


Chronological Thread 
  • From: Lamont Granquist < >
  • To: Thom May < >
  • Cc: Bryan McLellan < >, Chef Dev < >, Bryan McLellan < >, Phil Dibowitz < >
  • Subject: [chef-dev] Re: Re: Re: Re: releases, github milestones, etc.
  • Date: Tue, 05 May 2015 12:55:01 -0700



On 05/05/2015 09:41 AM, Thom May wrote:
" type="cite">
On Tue, May 5, 2015 at 5:01 PM, Lamont Granquist < " target="_blank"> > wrote:



 
Well, but there's no actual difference between the 12.3 branch and the 12.3.0 tag at this point, is there? And if we need to we can cut a 12.x branch off a 12.x.0 tag, in the future.
 

In the past, at any rate, its often been fussier, with stuff needing to get cherry-picked from master in order to fix a release before it even gets through omnitruck.  There's also the question of rc's.  If you try to tag the rc and later tag the release off of master then the rc won't accurately reflect the features shipping in master unless there's some kind of freeze on master.  So generally we want to branch and release the rc, then cherry pick any fixes then cut the release off of that, while master is still moving forwards.

" type="cite">
Once we're just shipping nightlies of master constantly and releases just bless a nightly with being stable this all changes, but you will eliminate the ability to stabilize releases if you stop using branches entirely right now.  And we're still not releasing weekly.



As a side note, release numbering is going to become pretty weird in the future.  Patch versions make little sense.  And if we're promoing nightlies then how do we bump the minor version?  People are very used to talking about 12.1, 12.2, 12.3, etc and if we change that and release look more like build numbers -- 12.56, 12.85, 12.143, etc then they'll feel like you just moved their cheese.  We also need to coordinate that with bumping the lib/chef/version.rb and releasing the gem to rubygems.


Yes. I guess I had been thinking that we'd keep a "more traditional"  version number and just append the build number in some way, so that chef would report "12.3.0 build 97" or whatever. And then the promotion becomes a lot simpler.

Yeah, but we also have gems to consider and at some point we need to make meaningful bumps to the minor and/or patch revs, and its not clear what event triggers either of those to bump.  If its constantly moving forwards it seems to me like the only meaningful number is really "build 97" so it'd be more accurate to just have 12.97.0 that we ship.




Archive powered by MHonArc 2.6.16.

§