OSGi is major.minor.micro.qualifier[1] which is essentially semver[2] with a qualifier where the qualifier in both cases is some element like a build number or time. I think the first three elements can become definitively useful employing something akin to the Eclipse API tooling (only works for OSGi bundles but the bytecode analysis techniques can be used and there are libraries for this that exist).
[1]: http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/Version.html On Jan 4, 2015, at 7:31 PM, William Ferguson <william.fergu...@xandar.com.au> wrote: > 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 >> >> Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. -- John Kenneth Galbraith
