A few thoughts: 1. How would people feel about calling it 1.0.0? Is there something specific we're hedging on by calling it a "0." release?
2. If I'm reading this correctly, you're suggesting weekly releases if there are code changes. With only 6 PMC members who have binding votes, it's a lot to ask of a small number of people. I see a risk of many of these votes fizzling out and expiring without getting enough binding votes. How would you feel about a longer regular cadence, such as monthly, with the option to invoke additional out-of-band releases as needed for critical fixes? The proposed mechanics of releasing look great to me. Please feel free to proceed with trying it. --Chris Nauroth On 12/10/15, 10:40 AM, "Allen Wittenauer" <[email protected]> wrote: >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 > >
