Works for me. Thanks for the quick response! On Wed, Mar 23, 2016 at 3:09 PM, Gwen Shapira <g...@confluent.io> wrote:
> 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 > > > -- Grant Henke Software Engineer | Cloudera gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
