On Dec 15, 2014, at 1:49 AM, Kristian Rosenvold <kristian.rosenv...@gmail.com> wrote:
> I somehow think we need to decide if we want to change anything :) > We certainly don't have to. I'm describing a system that's been implemented and it's working but I'm not expecting as a certainty that it's integrated here. I believe it's necessary which is why we built it for a customer. > 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. > The qualifier usually incorporates some temporal aspect and you just pick a build along the continuum that is deemed fit for release. > 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. > No, the 2.5.3 version in your case is only the marketing version in what I described. All artifacts that are part of the deployment are fully qualified and have the full version contained within them. This is for a simple deployment. It's get more complicated when you are trying to release a graph of related projects. > 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. > Sure, it's broken but I am assuming all references to its use are versioned and they will just have to move ahead to try it which means specifying an exact version. > Testers with pervious maven versions would have to follow the "old" rules. > Not sure what you mean by the old rules. The failed version is just discarded, testers use a new version and carry on. Though there is a distinction between using something like a Maven distribution vs a library. If a library build failed then a tester is going to have to update the version they are using. I don't think there is any magic that is sufficient, or desirable, that lets people reuse a version in any form. > Does this blend ? > I think the only point I can see where I don't agree is that the payload always gets the marketing version. I don't think that works. > (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 > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt
