Is there any reason not to use x.y.NN? The z qualifier is really used for fixes to x.y. So I can't see how it is different to a released x.y.NN
This would then keep the version numbers compatible with OSGi versioning. And do we really want a fourth qualifier? William ᐧ On Sat, Jan 3, 2015 at 8:49 PM, Hervé BOUTEMY <herve.bout...@free.fr> wrote: > IMHO, we should just make "lazy RC" > ie: > 1. prepare it like a release (with a tag in SCM) > 2. but no VOTE: just a one week TEST period, to let people discover and > report > if there is some issue > > once we have one testing week, we can do a classical x.y.z release: there > are > few chances the release will be cancelled. > > Regards, > > Hervé > > Le dimanche 14 décembre 2014 20:29:45 Jason van Zyl a écrit : > > 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%20AN > > D%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 > >
