mahout-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Musselman <andrew.mussel...@gmail.com>
Subject Re: Mahout release process
Date Wed, 10 Jul 2013 17:00:00 GMT
That's how the maven release plugin does it in my experience, and yes
that's what I get now too.


On Wed, Jul 10, 2013 at 10:54 AM, Jake Mannix <jake.mannix@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 <srowen@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ć <sslavic@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message