geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet" <gno...@gmail.com>
Subject Re: [DISCUSS] Release process change
Date Fri, 22 Dec 2006 22:57:15 GMT
Just some thoughts on the QA stuff.

>From what I understand, the problem you are focusing on
is just a naming problem: you want the GA release to be
named 2.0.  That's fine.  But it only concerns the final
downloadables archives, right ?  These are usually
downloaded from the Apache mirroring system, and
uploaded manually (not by maven).  So we can freely
rename them before uploading.
This would lead to using maven release to perform
the first release, named 2.0.0.0 and start a QA cycle.
If a new version is to be made, you can call it 2.0.0.1
and so on, until we are satisfied.
When the release is voted, we keep these binaries,
renamed then to 2.0 and upload them to the mirroring
system.  At the same time, you move the individual
artifacts from the staging repo to the official repo.

What I mean, is that when Geronimo releases a 2.0 version,
this is a "marketing" version number.  All the artifacts inside
are not in version 2.0:  openejb, activemq and all other
external dependencies have their own lifecycle.  So I don't
really see a big problem if modules and configurations have
a different version number from the final Geronimo release.

If you find it too cumbersome, let's say we revert back
the modules to 1.3, and we use them to release a 2.0.
It would become more obvious I think.

I don't imply this is the best solution, but it may be one.
Thoughts ?

On 12/22/06, Jason Dillon <jason@planet57.com> wrote:
> On Dec 22, 2006, at 11:14 AM, David Jencks wrote:
> > I thought from looking at the maven dev list that maven now or in a
> > couple days is going to support staging releases.  I'm considerably
> > less than thrilled by the idea of changing what we vote on,
> > especially just when it looks like hope is on the horizon.
>
> I'm not convinced that the recent work from the mvn team to improve
> the release process for mvn projects is going to solve the release
> problem... I do believe that it is a step forward, but there are
> still a few major issues which I don't see being addressed yet.
>
> One of the big problems is certification of binaries, and release
> build iteration.  For example, many shops generally like to produce a
> set of release artifacts, promote them to QA, let QA perform some
> battery of tests and then bless the binaries.
>
> To accomplish this with mvn (today and even tomorrow or whenever the
> new release support plugins are finished) means that a "real" release
> must be made for each iteration to QA, and when QA comes back and
> rejects a release, code must be altered and a new release must be
> made and the cycle continues until one of blessed.  In mvn terms that
> means that version 1.0.0 might get passed to QA, rejected, and then
> 1.0.1 is spun and handled to QA, rejected... etc... maybe the
> *actual* release is 1.0.3, instead of 1.0.0 which users are expecting.
>
> IMO, the problem with mvn releases, is that there is so much version
> encoding in each artifact (name, embedded poms and dependency
> configuration) that it is not possible to take a set of binaries and
> promote them from a DEV release, to QA release to a final blessed
> release.  You must in each case rebuild to change versions, and by
> rebuilding some of the certification is essentially lost.  You and I
> might both know that only version number have changed... but it is
> possible that when changing versions to make a release build that
> something else in your environment has changed (say different JDK was
> used), or perhaps the previously downloaded artifact cache was lost,
> and the build must download new dependencies, which could potentially
> be altered, producing output artifacts which are different.
>
> Unfortunately mvn can not even take a previously build set of
> binaries in a projects target directory and simply install or deploy
> them... but in order for it to deploy it must go through and run the
> previous phases and will re-generate jars and other artifacts.  So,
> you can't even really be 100% sure that in a simple local
> environment, that building artifacts, performing some set of test,
> and then deploying will actually deploy the same set of artifacts
> that you tested with.  Unfortunately mvn differs greatly from ant
> projects in that it tends to redo work instead of detecting that no
> changes are needed and skipping steps.  While it will only recompile
> changed sources (for java at least), it will always at the end
> regenerate a jar and install it into the local repo.
>
> So far I do not see the mvn folks making any progress on solving this
> problem... and IMO, this is required if you are going to certify
> binaries.
>
>
> > I'm definitely in favor of releasing the specs now, but I'd be more
> > comfortable voting on binaries as we have in the past.
>
> Unfortunately, to do this... if there is a problem with one of the
> binaries, they must be rebuilt using the same version numbers, so its
> not easy to tell which artifacts are from which iteration.  Only way
> around this IMO is to use a separate staged deploy directory for each
> iteration... which isn't something that can be easily enforced/
> automated by mvn itself, so this ends up being a potential problem
> when running a release, to make sure you configure the iteration when
> publishing for certification.
>
>   * * *
>
> I don't think that projects using mvn should really need to use mvn
> to make releases... but unfortunately due to the complexity of
> actually making a release for a mvn 2.x project it is a necessity.
> With all those versions and scm bits to update... users are kinda
> forced to use the release plugin.
>
> And... I don't think that every single artifact which is included
> into a server build should be "released".  For the server, the
> release is the assembly zip/tgz... mvn forces us to release
> *everything* that is used to make those assemblies and IMO is a huge
> mistake.
>
>   * * *
>
> When it comes to building a project, mvn does a pretty good job,
> better job with out snapshots.
>
> Its plugin system is really getting to be solid and functional,
> though some of the bugs are forcing people to implement potentially
> dangerous workarounds.
>
> Actually building artifacts is reasonable, though most plugins tend
> to always redo work, so re-running a build that is already built will
> redo a bunch of stuff, which just slows things down and introduces
> unwanted side-effects.
>
> Site generation is novel, though most mvn sites are basically clover,
> javadocs and xrefs with a bunch of meaningless negative space gluing
> them together.  Most people I've show site docs to are confused by
> what they re looking at and find it hard to find the interesting bits
> (javadocs, clover, xref).  And for actually project docs, I find wiki
> is much better... so unless a project actually intends to customize
> its mvn site for its official website I think the who `mvn site`
> thing is more of a waste.
>
> But when it comes to releasing things built with mvn... well, mvn has
> a long way to come before its anything which I could consider ideal
> (or even close to ideal).
>
> --jason
>


-- 
Cheers,
Guillaume Nodet

Mime
View raw message