maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hervé BOUTEMY <>
Subject Re: Releases, Continuous Delivery and the Future
Date Sat, 03 Jan 2015 10:49:32 GMT
IMHO, we should just make "lazy RC"
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.



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:
> 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
> ---------------------------------------------------------
> 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:
For additional commands, e-mail:

View raw message