While we are discussing this, Sean and I are going to try and run through this process over the next 24 hours to see if there are kinks with the goal of cutting a real (yes, really!) RC as a potential release. If anyone wants us to hold back, let us know pretty quickly. ;)
Thanks! > On Dec 10, 2015, at 10:29 AM, Sean Busbey <[email protected]> wrote: > > Hi folks! > > We'll be getting to our first set of release candidates shortly, and > there are a couple of open questions we need to get some consensus on. > > > 1) Release Staging > > As a part of making release candidates, a release manager needs to > update the version number from in-progress to whatever the release > will be (i.e. 0.1.0-SNAPSHOT to 0.1.0). > > I suggest we take on a common strategy that I've seen work well before: > > * create a staging branch (i.e. 0.1.0-staging) > * add a commit with the to-be-voted-on version number > * generate an RC > * if RC feedback results in more changes to the master branch, cherry > pick as needed > * (loop on generating RCs) > * When a VOTE passes, create a release tag for the commit hash that > passed and delete the branch > > Current restrictions on deleting refs aside, this gives us a place > away from the main branch to make janitorial changes, a well-defined > place to start any future maintenance branches, and it keeps our > branches limited to those that are active right now. > > 2) Release timelines and cadence > > ASF policy requires that release votes be atleast 72 hours, everything > else is up to us. As we gain adoption we're likely to be in the > critical path for other development shops, so I'd like us to take an > aggressive stance on getting changes out into releases. > > Presuming there have been changes since the prior release, how about > we aim for a schedule of calling a release vote every Friday ~noon PT > that closes at Monday ~noon PT? > > -- > Sean
