You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@mahout.apache.org by Stevo Slavić <ss...@gmail.com> on 2013/07/10 11:11:30 UTC

Mahout release process

This is continuation of my and Grant's discussion on
https://issues.apache.org/jira/browse/MAHOUT-1275 which I believe is better
suited to be continued here on the dev mailing list.

Apologies for my ignorance, if this discussion took place earlier in the
project lifetime.


There is no 0.8 branch here: http://svn.apache.org/viewvc/mahout/branches/
maven-release-plugin:prepare creates a tag only, which (in svn) although
similar to branch, shouldn't be modifiable, and we need it to be modifiable
if something needs to be changed for final 0.8 release, without
stopping/freezing 0.9 development.
Release instructions basically state that if something is wrong with RC
release, to delete RC release (drop staging repo and delete tag from svn),
rollback version changes on trunk (from 0.9-SNAPSHOT back to 0.8-SNAPSHOT),
make a fix on trunk, and prepare/perform RC release again (same 0.8 release
version).
Current 0.8 RC, IMO is not a proper RC - if we need to make a change to it
and release another RC, there would be no obvious distinction between the
two RCs, especially to Maven builds that Mahout users are likely to be
using, so even after second RC they might still be using/testing with the
old one (cached/resolved in their local repo) as Mahout Maven artifact
coordinates didn't change (same 0.8 version for both RCs).

In workflow I mentioned (in MAHOUT-1275 comment) - we'd make 0.8.x branch
(with maven-release-plugin branch goal), then from that branch make 0.8.RC1
release (release:prepare/perform), with 0.8.x branch POMs staying on
0.8-SNAPSHOT; then if something is found to be wrong with 0.8.RC1, we could
modify the branch (merge the change to 0.9-SNAPSHOT on trunk), and make
another 0.8 RC release, but now of 0.8.RC2 version (different Mahout Maven
artifact coordinates), and so on; when 0.8.RCX is acceptable, passes vote,
we'd make another release or promote 0.8.RCX, to 0.8 or 0.8.FINAL. Final
one would be published on release repository, while all the RCs on staging
repo. Before final release, 0.8.x branch would have 0.8-SNAPSHOT version in
POMs. Branch 0.8.x after final release could have 0.8.1-SNAPSHOT version,
for any critical support changes in future, before 0.9 release.
During whole time of forging 0.8 RC and final releases on their own 0.8.x
branch, 0.9-SNAPSHOT development on trunk can go on. Also, there would be
no rollbacks necessary for RC releases (with exception of cases when it's
really necessary, e.g. when release of some RC is incomplete/breaks because
of network failure or something similar). Also tags stay non-modifiable.

I noticed at least one Apache project to follow this release workflow (with
staging RCs with different Maven coordinates, and promoting an RC to final
release), namely on Apache HttpComponents project.

I could understand current release process, if idea is to have all hands
focused on the release while it's being made/tested, and also making it
obvious to community (with absence of branches other than trunk) that there
is no support whatsoever possible/available via minor releases, apart from
changes on trunk and next major release.

Kind regards,
Stevo Slavić.

Re: Mahout release process

Posted by Andrew Musselman <an...@gmail.com>.

I have to admit I spent as little time as possible learning how to do maven
releases so I don't know the answer to this.


On Wed, Jul 10, 2013 at 11:06 AM, Jake Mannix <ja...@gmail.com> wrote:

> On Wed, Jul 10, 2013 at 10:00 AM, Andrew Musselman <
> andrew.musselman@gmail.com> wrote:
>
> > That's how the maven release plugin does it in my experience, and yes
> > that's what I get now too.
> >
>
> Ok, that's fine if it's intended, but it seems to put us in a little bit of
> a weird state.  We tell
> our users often to build on trunk, so if they're using the current most
> recent release (0.7),
> then if they do that now, they go from 0.7 to 0.9-SNAPSHOT.  Not the end of
> the world,
> but this would be avoided if we were on a release branch, right?
>
> Maybe next time, we can do that?
>
>
> >
> >
> > On Wed, Jul 10, 2013 at 10:54 AM, Jake Mannix <ja...@gmail.com>
> > wrote:
> >
> > > So quick question: is an intentional side-effect of the current release
> > > process that when we build on trunk now, we build artifacts named e.g.
> > > mahout-examples-0.9-SNAPSHOT-job.jar ?
> > >
> > >
> > > On Wed, Jul 10, 2013 at 2:33 AM, Sean Owen <sr...@gmail.com> wrote:
> > >
> > > > Yes you can do all of this in a branch, which would let things
> > > > continue to change on HEAD. Otherwise HEAD has to be frozen. I think
> > > > here there's not enough velocity of change to make freezing HEAD that
> > > > big of a deal, but yes you could manage the process yourself in a
> > > > branch if you wanted to.
> > > >
> > > > Tags are changeable in SVN. Nobody is depending on the tag until
> after
> > > > the release is finalized, so moving them during the release or
> > > > reapplying them is no big thing.
> > > >
> > > > The release process doesn't update Maven artifacts, even snapshots,
> so
> > > > the process does not affect what artifacts end users use.
> > > >
> > > > RCs are indeed all labeled "x.y" but are certainly distinguished by
> > > > date, timestamp. It's not a RC in the sense that it may evolve and
> > > > change in response to bug fixes over weeks or months -- it's either a
> > > > valid build or it isn't right now, and is released or not in a few
> > > > days unless there is a critical build problem. It will only be
> > > > developers that might ever distinguish several builds.
> > > >
> > > > You can use x.y.z for sure and I personally would be happy to see
> > > > "0.8.0" used instead of "0.8". That is technically more standard
> Maven
> > > > convention. I don't think there will be enough change / energy for
> > > > point releases but it doesn't hurt to allow for the possibility.
> > > >
> > > >
> > > > On Wed, Jul 10, 2013 at 10:11 AM, Stevo Slavić <ss...@gmail.com>
> > > wrote:
> > > > > This is continuation of my and Grant's discussion on
> > > > > https://issues.apache.org/jira/browse/MAHOUT-1275 which I believe
> is
> > > > better
> > > > > suited to be continued here on the dev mailing list.
> > > > >
> > > > > Apologies for my ignorance, if this discussion took place earlier
> in
> > > the
> > > > > project lifetime.
> > > > >
> > > > >
> > > > > There is no 0.8 branch here:
> > > > http://svn.apache.org/viewvc/mahout/branches/
> > > > > maven-release-plugin:prepare creates a tag only, which (in svn)
> > > although
> > > > > similar to branch, shouldn't be modifiable, and we need it to be
> > > > modifiable
> > > > > if something needs to be changed for final 0.8 release, without
> > > > > stopping/freezing 0.9 development.
> > > > > Release instructions basically state that if something is wrong
> with
> > RC
> > > > > release, to delete RC release (drop staging repo and delete tag
> from
> > > > svn),
> > > > > rollback version changes on trunk (from 0.9-SNAPSHOT back to
> > > > 0.8-SNAPSHOT),
> > > > > make a fix on trunk, and prepare/perform RC release again (same 0.8
> > > > release
> > > > > version).
> > > > > Current 0.8 RC, IMO is not a proper RC - if we need to make a
> change
> > to
> > > > it
> > > > > and release another RC, there would be no obvious distinction
> between
> > > the
> > > > > two RCs, especially to Maven builds that Mahout users are likely to
> > be
> > > > > using, so even after second RC they might still be using/testing
> with
> > > the
> > > > > old one (cached/resolved in their local repo) as Mahout Maven
> > artifact
> > > > > coordinates didn't change (same 0.8 version for both RCs).
> > > > >
> > > > > In workflow I mentioned (in MAHOUT-1275 comment) - we'd make 0.8.x
> > > branch
> > > > > (with maven-release-plugin branch goal), then from that branch make
> > > > 0.8.RC1
> > > > > release (release:prepare/perform), with 0.8.x branch POMs staying
> on
> > > > > 0.8-SNAPSHOT; then if something is found to be wrong with 0.8.RC1,
> we
> > > > could
> > > > > modify the branch (merge the change to 0.9-SNAPSHOT on trunk), and
> > make
> > > > > another 0.8 RC release, but now of 0.8.RC2 version (different
> Mahout
> > > > Maven
> > > > > artifact coordinates), and so on; when 0.8.RCX is acceptable,
> passes
> > > > vote,
> > > > > we'd make another release or promote 0.8.RCX, to 0.8 or 0.8.FINAL.
> > > Final
> > > > > one would be published on release repository, while all the RCs on
> > > > staging
> > > > > repo. Before final release, 0.8.x branch would have 0.8-SNAPSHOT
> > > version
> > > > in
> > > > > POMs. Branch 0.8.x after final release could have 0.8.1-SNAPSHOT
> > > version,
> > > > > for any critical support changes in future, before 0.9 release.
> > > > > During whole time of forging 0.8 RC and final releases on their own
> > > 0.8.x
> > > > > branch, 0.9-SNAPSHOT development on trunk can go on. Also, there
> > would
> > > be
> > > > > no rollbacks necessary for RC releases (with exception of cases
> when
> > > it's
> > > > > really necessary, e.g. when release of some RC is incomplete/breaks
> > > > because
> > > > > of network failure or something similar). Also tags stay
> > > non-modifiable.
> > > > >
> > > > > I noticed at least one Apache project to follow this release
> workflow
> > > > (with
> > > > > staging RCs with different Maven coordinates, and promoting an RC
> to
> > > > final
> > > > > release), namely on Apache HttpComponents project.
> > > > >
> > > > > I could understand current release process, if idea is to have all
> > > hands
> > > > > focused on the release while it's being made/tested, and also
> making
> > it
> > > > > obvious to community (with absence of branches other than trunk)
> that
> > > > there
> > > > > is no support whatsoever possible/available via minor releases,
> apart
> > > > from
> > > > > changes on trunk and next major release.
> > > > >
> > > > > Kind regards,
> > > > > Stevo Slavić.
> > > >
> > >
> > >
> > >
> > > --
> > >
> > >   -jake
> > >
> >
>
>
>
> --
>
>   -jake
>