I somehow think we need to decide if we want to change anything :) Without changing anything there seem to be only "so" many approaches out there, this is well known territory. While initially confusing, jetty's 9.2.3.v20140905 approach is quite good. I assume they might have had a failing " 9.2.3.v20140902" a few days before that we never got to see. It still gives the silly suffix on the name, and I think we might do one better.
We change something in maven core, introduce a clearer separation of dependency-version (as-referenced version ) and artifact version: (Using the currently staged assembly-plugin 2.5.3 at https://repository.apache.org/content/repositories/maven-1103 as en example) The artifact is *always* called 2.5.3 in the pom version (what we all know as artifact-version). It's even deployed to these GAV coordinates in staging nexus. The signature signs a 2.5.3. version. In the vote mail we refer to the version as 2.5.3.v2014-12-13. Seeing this version number, maven 3.3+ writes download the artifacts to the folder ~/.m2/repository/org/apache/maven/plugins/maven-assembly-plugin/2.5.3.v2014-12-13 The tester tests a version named 2.5.3.v2014-12-13. If I re-roll the version will be 2.5.3.v2014-12-15. The payload is always version 2.5.3. If the 2.5.3.v2014-12-13 is broken, the stage at https://repository.apache.org/content/repositories/maven-1103 is dropped and all the testers/integrators are left with a broken ~/.m2/repository/org/apache/maven/plugins/maven-assembly-plugin/2.5.3.v2014-12-13 artifact, waiting for a replacement. Testers with pervious maven versions would have to follow the "old" rules. Does this blend ? (I have not entirely sorted out how this differs from fixing problems with snapshots and using numbered snapshots instead. ) Kristian Sat Dec 13 08:35:33 2014-12-15 2:29 GMT+01:00 Jason van Zyl <ja...@takari.io>: > Hi, > > The discussion keeps resurfacing about how we deal with failed releases so > I'll summarize how I think it should ultimately be done as a starting point. > > I'll go over the cases we've encountered thus far: > > 1) The user case prefers non-disjunct sets of releases, or from our PoV > re-used versions. I believe people are confused by missing versions and will > always result in questions like "What happened to version X?", where X is a > non-viable build. Not many people read release notes, will not self-serve and > it will just be a lot of questions and confusion. The typical user doesn't > care about the question of whether a particular build is viable or not. I > think they naturally expect contiguous, increasing versions when they update > to new versions of a product. > > 2) The tester case prefers new versions but has tolerated re-used versions. > Testers for core only really have to deal with the binary distribution and if > it gets thrown away there's not much chance of local repository inconsistency > because the typical tester, who is not an integrator, isn't going to depend > on the new core release for anything. Running 3.2.4 doesn't put anything > related to 3.2.4 in your local repository. > > 3) The integrator case prefers new versions. Different content with the same > version is a violation of our immutability philosophy and can cause issues. > Even though this is very much contained at the moment let's be optimistic and > believe we will have many integrators that will test pre-released versions. > Igor is right in that it's not fun to keep track of this and why should the > burden be placed on the integrator. The answer is it shouldn't. > > 4) The release manager case prefers new versions. I have typically reused > versions because I believe 1) is true. It's a PITA to erase tags, shuffle > issues around in JIRA, and reset the POMs. I would prefer to just move > forward, but I have done it because the user confusion is not worth the small > effort it takes me to clean up a few resources. One hour for me versus > thousands of hours of confusion for all users. It's an easy calculation. > > Taking all these cases into consideration so that all participants are > satisfied I think we ultimately want increasing and contiguous versions for > users, testers and integrators while the release manager does not have to > shuffle a bunch of resources around in the event of a non-viable build. What > we want is a form of continuous delivery where a version like 3.2.4 is the > version that we call it to the outside world (some refer to it as the > marketing version) and the qualifier changes from build to build so we have: > > 3.2.4-qualifier > > And for simplicity's sake let's just say the qualifier is a build number so > we end up with: > > 3.2.4-01 > 3.2.4-02 > ... > 3.2.4-NN > > Every build is a complete build that can be released, and in the stream of > builds that are produced we decide that one is good enough for public > consumption. Nothing in the issue tracking or documentation needs to change > as it's still referred to as 3.2.4. People who download the distribution > aren't going to care what the exact versions say on the JARs but some > education might be required to tell people that something like 3.2.4 is > actually 3.2.4-05 if they want to refer to an artifact from 3.2.4. I don't > think making aliases to the marketing versions are a good idea and wouldn't > want to duplicate artifacts so that they can be referred to by the marketing > version. People will just become accustom to knowing a qualifier is necessary > to find the actual version. > > This is more how things work at Eclipse where if you look at something from > Jetty: > > http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.eclipse.jetty%22%20AND%20a%3A%22jetty-servlet%22 > > You'll see that something like jetty-servlet 9.2.3 is actually referred to as > 9.2.3.v20140905. Jetty seems somewhat inconsistent with respect to milestones > but you get the idea. I think this works for all parties but especially users > where say we all happen to write blog entries about 3.2.4 and it fails twice > and we actually release 3.2.6. This is just so confusing as anything that > referred to 3.2.4 now really means 3.2.6 which is totally inconsistent. I > think skipping failed versions from the users perspective like we are > currently doing is just a recipe for a massive amount of confusion and wasted > time. Moving toward a stream based approach with a marketing version and > qualifiers for actual versions is really the only way it can work for > everyone. > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/takari_io > --------------------------------------------------------- > > To think is easy. To act is hard. But the hardest thing in the world is to > act in accordance with your thinking. > > -- Johann von Goethe > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
