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
