mahout-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Lyubimov <dlie...@gmail.com>
Subject Re: Mahout release process
Date Wed, 10 Jul 2013 21:05:05 GMT
i thought maven release:prepare changes from 0.8-SNAPSHOT to 0.8 (and
eliminates snapshot dependencies). and release:perform goes from 0.8 to
0.9-SNAPSHOT. I.e. it guarantees that by the time you have 0.9-SNAPSHOT
set, you also have a released 0.8 build.

but for some reason it is not what is happening now on trunk.


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

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