OK, well, classifiers works for me, then. It certainly seems like SNAPSHOTs are not the go-forward plan, at least, without your fix.
Is it true that you can't use 4 part versions with Maven without confusing some logic that is hard coded to look for 1.2.3 rather than N.N+1.N+2....N+M ? If not true, you could just step up to 4 and use up minor minor steps. Fred. On Mon, Dec 15, 2014 at 3:11 PM, Jason van Zyl <ja...@takari.io> wrote: > A further definition of a qualifier is that it applies to all artifacts in > a multi-module project (MMP). Unfortunately, at present, SNAPSHOTs are > fundamentally flawed in that all artifacts produced in an MMP do not get > the same timestamp. Each artifact gets its own which makes it impossible to > refer to the MMP with a single version. This is highly problematic and was > certainly a design oversight 10 years ago.I have code that remedies this > but it's only one aspect of moving toward continuous delivery in that all > builds produced at all times need to be releasable. So in the builds that I > work on everything required for a release is enabled including source JAR > generation and any checks. I have had customers in the past that went > through all sorts of contortions to collect all the various snapshot > versions for a release to mimc something like CD but it's certainly not > ideal. > > On Dec 14, 2014, at 8:44 PM, Fred Cooke <fred.co...@gmail.com> wrote: > > > Thank ****/***, finally some movement in the right direction! :-D > > > > Please also try to remember that EVERY single one of your "users" is a > > *developer* and should comprehend that a version is an arbitrary label > on a > > piece of software to be used to uniquely identify it. If not, they should > > be educated. > > > > Thanks for putting some time into this. Qualifiers suit me fine. As long > as > > they're immutable, I'm happy. > > > > Another approach is: SNAPSHOTs until you're actually confident, then > > release a real one, and if it sucks, release another post more snapshots. > > This is the entire point of snapshot builds in the first place, right? > Just > > my 2c. > > > > /me goes back to lurking. > > > > Regards, > > > > Fred. > > > > On Mon, Dec 15, 2014 at 2:29 PM, Jason van Zyl <ja...@takari.io> wrote: > > > >> 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 > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/takari_io > --------------------------------------------------------- > > We know what we are, but know not what we may be. > > -- Shakespeare > > > > > > > > > >
