You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Gwen Shapira <gw...@confluent.io> on 2016/03/23 20:06:31 UTC
[ANN] Small change to release process
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
Re: [ANN] Small change to release process
Posted by Grant Henke <gh...@cloudera.com>.
Works for me. Thanks for the quick response!
On Wed, Mar 23, 2016 at 3:09 PM, Gwen Shapira <gw...@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 <gh...@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 <gw...@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
> > grant@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
> >
>
--
Grant Henke
Software Engineer | Cloudera
grant@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
Re: [ANN] Small change to release process
Posted by Gwen Shapira <gw...@confluent.io>.
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 <gh...@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 <gw...@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
> grant@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
>
Re: [ANN] Small change to release process
Posted by Grant Henke <gh...@cloudera.com>.
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 <gw...@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
grant@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke