geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: [DISCUSS] Release process change
Date Sat, 23 Dec 2006 00:01:39 GMT
On Dec 22, 2006, at 2:57 PM, Guillaume Nodet wrote:
> 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 ?

Nope, since mvn releases each component's artifact separately, its  
not just the zip/tgz that one traditionally thinks of as the  
release... its every single artifact that gets spit out of the  
release.  For this to work in mvn, the version of everything needs to  
change together, so that you can be sure that one release is using  
the right set of binaries vs. another.  Otherwise you have to set the  
version of the project to 2.0.0 and then you could go through many  
iterations which all use the same version, which means deploying them  
over previous version and the end result is that you can never be  
certain which version of 2.0.0 you end up including into your build.

To avoid publishing all of these binaries over and over the mvn way  
is to make the project as a SNAPSHOT (like 2.0.0-SNAPSHOT) which will  
deploy new artifacts using timestamps to avoid clobbering previous  
version... BUT, when it comes time to actually make one of those a GA  
release, then you have to update source code, rebuild and the end  
result might be something quite different than the previous release  
that every one has certified and voted upon.  Its far to easy to make  
a small mistake in the build process to dramatically alter the build  
outputs... especially since you need to make source code changes (and  
lots of them) to flip the version.


> 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.

Yup, this means that 2.0.0.1 - 2.0.0.x will end up into the central  
sync repo and pushed out to mirrors.  Not ideal.  This can be avoided  
by using a profile to set the distribution URL to something else (and  
hope that people don't forget to enable that profile)... and then you  
are forced to use mvn repo copy stuff (which was just added) to  
perform the official deploy from a staged repo.  Which... well,  
hopefully will just work, if not then we risk corrupting metadata on  
releases, which would be very bad.

That is a bunch of intermediate steps we must go through to work  
around deficiencies in a mvn projects releasability.  The more steps,  
the more chances that something will go wrong or that someone will  
miss something.

This is really a huge PITA from a build release managers  
perspective... massive hoops to jump through to get mvn closer to  
(yet still far off from) a simple release process.

IMO, many of these problems go away when you don't need to deploy/ 
publish every single intermediate artifact, or are lessened if you  
could deploy a previously build artifact with out needing to rebuild  
it.  The whole need to rebuild artifacts to deploy is a huge hole...  
you can't be sure that artifacts built with `mvn install` will be the  
same artifacts used for `mvn deploy`.  In most cases the artifacts  
will change.  So you can't really run ` mvn install` to ensure that  
your build completes and then `mvn deploy` to simply publish what was  
recently built.  And you can't safely just `mvn deploy` and if that  
fails halfway through, then you end up with a half deployed release.   
And for a large project like Geronimo server, cleaning up all those  
release turds is a PITA... and really, re-releasing the same version  
over it just causes more potential problems, as others might have  
already started to consume parts of the newly deployed partial  
released artifacts.


> 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.

You could do that, really only for the zip/tgz bits... though that  
adds more manual steps, as well as introduces some inconsistence with  
the versions of internal artifacts.  If internally we did not use the  
same mvn style repo with version information all over everything,  
then I think this would work okay, but we have version muck all over  
everything inside of Geronimo.  But that is not the case, so you will  
download 2.0 and find that its really 2.0.0.3 and then download 2.1  
and find that its really 2.1.0.5, not really what one might expect.   
It might be more of a cosmetic problem, but we've already see  
requests from Hernan for screen shots to strip out #rev numbers and  
such.


> 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.

No perhaps not... but this is more external hacking around mvn  
release deficiencies.  More external process to manage and thus more  
that could possible go wrong :-(

But, we'll see... maybe the new release support that the mvn team is  
working on will help reduce some of the hacks around releasing and  
streamline it.  My guess is that it might help... but they are still  
far off from solving the problem, and that is more due to the  
architecture of mvn than anything else.


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

I'm not sure there is a best solution to this problem right now...  
and I'm not sure that there is one on the horizon.  I think we can  
probably find a solution that is good enough for now though... but  
far from air tight.

--jason



Mime
View raw message