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
