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
