maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <denn...@apache.org>
Subject Re: Releases, Continuous Delivery and the Future
Date Wed, 17 Dec 2014 13:20:47 GMT
For JIRA there is an easier way to handle this: you rename the
version(s) in JIRA.

If 3.2.4 fails, rename it to 3.2.5.

Additionally if there are more future patch versions in JIRA, then
they need to be renamed first.

If 3.2.4 fails , and in JIRA we have 3.2.4, 3.2.5 and 3.2.6, then we
end up with 3 renames to do in JIRA:
3.2.6 -> 3.2.7
3.2.5 -> 3.2.6
3.2.4 -> 3.2.5

There are several benefits of doing this:
* We are working with (patch) versions in JIRA instead of issues =
less work for the RM
* No notifications emails are sent from JIRA for version renames
* The versions in JIRA matches exactly the versions that were actually released



On Mon, Dec 15, 2014 at 10:36 PM, Paul Benedict <pbenedict@apache.org> wrote:
> Jason, thanks for taking the time to write this up. It is a good read.
>
> One extra tidbit I'd like to discussion is this. When I recommended we burn
> the version when the vote/build fails, I wasn't expecting we would move the
> fixed issues to the new version. Let's not do that. I find that confusing
> because it's impossible to keep track which issues are tied to what vote.
> For example, when 3.2.4 failed with 20 fixed issues, I want to see the
> 3.2.4 issues stay as-is and 3.2.5 to have new issues. We don't need the
> extra JIRA maintenance of moving issues when a version is burned, and,
> overall, it is a better historical record of the facts. WDYT?
>
>
>
> Cheers,
> Paul
>
> On Sun, Dec 14, 2014 at 7:29 PM, Jason van Zyl <jason@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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>



-- 
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message