It was decided (rather unilaterally by your humble release manager), but that doesn't mean decisions can't change :)
1. We can definitely have multiple tags for each separate RC. Actually I think this is better than moving the tag. 2. We can't change release artifacts after the vote, which mean that the artifacts we vote on must be 0.10.0.0. We can change the version in the branch itself from SNAPSHOT to RC (and still release 0.10.0.0 as candidates), but since SNAPSHOT has well defined semantics, I think it makes sense to keep it. Gwen On Wed, Mar 23, 2016 at 1:01 PM, Grant Henke <ghe...@cloudera.com> wrote: > Hi Gwen, > > Is the new release process already decided? If so you can ignore my > question below. > > Since we are making a change to the process. What do you think about > publishing release candidates using "RC" in the version? So instead of > re-using the 0.10.0.0 tag and using 0.10.0.0-SNAPSHOT as the version until > release. Instead each new release candidate changes the version and tag to > be 0.10.0.0-RC1, 0.10.0.0-RC2, etc. > > Thanks, > Grant > > > > On Wed, Mar 23, 2016 at 2:06 PM, Gwen Shapira <g...@confluent.io> wrote: > > > Hey Team Kafka, > > > > As you know, our current release process is: > > * Branch > > * Change version from 0.10.0.0-SNAPSHOT to 0.10.0.0 > > * Roll out a release candidate with version 0.10.0.0 > > * Fix bugs and keep rolling out release candidates > > * After vote passed and release was published, bump the branch to > > 0.10.0.1-SNAPSHOT > > > > As a result, we have multiple artifacts with same version but different > > content. Which is a huge no-no, and can cause technical issues with Maven > > repositories (clients may miss updates because they already have earlier > > releases cached and releases should be immutable. > > > > To streamline our process a bit, we are going to move to the following > > process: > > > > * Branch > > * Change the version on trunk to 0.10.1.0-SNAPSHOT but keep the branch > > version as 0.10.0.0 SNAPSHOT > > * Before every release candidate, we'll push a commit that changes > version > > to 0.10.0.0 to a tag and release from the tag. If needed, commits will go > > to the release branch with the SNAPSHOT version. > > * Once vote passes, we'll publish the release, merge the tag commit to > the > > branch, and bump the branch to 0.10.0.1-SNAPSHOT > > > > This is very similar to the process that Zookeeper community is following > > and will help anyone who builds against branches. > > > > As an awkward first step, I'm moving the 0.10.0.0 branch back to > > 0.10.0.0-SNAPSHOT. > > > > Sorry for the awkwardness, but this will improve things going forward. > > > > Gwen > > > > > > -- > Grant Henke > Software Engineer | Cloudera > gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke >
