You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@takari.io> on 2014/12/15 02:29:45 UTC
Releases, Continuous Delivery and the Future
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
Re: Releases, Continuous Delivery and the Future
Posted by Dennis Lundberg <de...@apache.org>.
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 <pb...@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 <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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Releases, Continuous Delivery and the Future
Posted by Paul Benedict <pb...@apache.org>.
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 <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
>
>
>
>
>
>
>
>
>
>
Re: Releases, Continuous Delivery and the Future
Posted by Robert Scholte <rf...@apache.org>.
Great wording, although I really hope that nobody read 3.1.1 as 311, as if
3.1.2 (or 312) must be the next version. 3.2.0 was very valid. We're
talking about major.minor.bugfix, each having its own value.
Just like people saying that 0.99 would be the final draft. Why? 0.100 (or
0.999 if you want to use only 9's) would be a valid final final draft ;)
Robert
Op Mon, 15 Dec 2014 11:00:11 +0100 schreef Stephen Connolly
<st...@gmail.com>:
> On 15 December 2014 at 01:29, 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.
>>
>
> I have not seen anyone asking what happened to 3.2.0
>
> Similarly I have not seen anyone asking what happened to 3.1.2, 3.1.3,
> 3.1.4, 3.1.5, 3.1.6, 3.1.7, 3.1.8 or 3.1.9
>
> And also nobody was visible to me about what exactly happened to
> 3.0.6-3.0.9 inclusive or the vast range of continuous numbers we skipped
> before 3.0.0
>
> I seem to recall a few questions about what da f*ck exactly was 2.0.10
> and
> was it newer than 2.0.4 but, you know what, our users are by and large
> reasonably smart people, they can read an answer if we provide one, and
> the
> user community itself can probably sort out explaining where any missing
> versions went, especially if we put the explanation on a page on our
> website...
>
> So this use case is, to my mind, not really relevant. I think we can
> divide
> our users into two large groups:
>
> a. Those users who have a mandated version of maven that they must use
> b. Those users who are happy to use the latest version of maven whatever
> that is
>
> There are other groups out there, but I believe that the above two groups
> covers at least 80% of our users
>
> A final point on the user community... if we treat our users like idiots,
> then that's the kind of users we will get.
>
> I don't know how the rest of you feel about our users, but I know that
> our
> users are by and large a reasonably smart group of people.
>
> I just plain do not buy this argument about users expecting contiguous
> increasing versions.
>
> I think users expect us to actually cut releases on a reasonably frequent
> basis and to fix things and generally not make things worse... and that
> we
> will have a page somewhere that is easy to find (probably called release
> history) that will let them track down when the thing they care about
> right
> now changed so that they can either fix or roll-back to Get Things Done™
>
>
>
>> 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.
>>
>
> This applies to core... but not so for testing plugins. We are not just a
> project about core. If we decide on a policy it should be a policy that
> works for both core and plugins.
>
> One thing we always complain about is the lack of testing in areas where
> our automated tests are weak.
>
> To combat that we need to grow our pool of testers to include people from
> the user community right now.
>
> Those users may not be as comfortable ensuring that they have cleared out
> their local repo of any side artifacts pulled in when testing a staged
> release...
>
> If they know that the artifact version number will never be re-used it
> gives them a bit more confidence.
>
> And this is not just about testing on your local machine, you might push
> the changes to your CI server via a pull request and a pull request
> builder
> to get even better test coverage. Then you have to worry that the CI
> server
> will have some build slaves with old pre-release versions.
>
> If we want to grow testing then I see re-use of versions a complete
> no-no.
>
>
>>
>> 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.
>>
>
> Again, from this use case I see re-use of versions as a complete no-no
> also.
>
>
>>
>> 4) The release manager case prefers new versions.
>
>
> When something is found wrong in 3.2.4 during voting, a user will create
> an
> issue in JIRA... found in 3.2.4... so we go and fix it... in 3.2.4...
> that
> just feels messy to me. I much rather say that an issue found in 3.2.4 is
> fixed in a later version...
>
> And before anyone asks, if the regression/issue was found in
> 3.2.4-SNAPSHOT
> and we don't want to have -SNAPSHOT versions in JIRA then the
> regression/issue gets fixed before the actual 3.2.4 gets released and the
> JIRA issue needs to be reclassified...
>
> * if it was a regression and we fix that before the regression gets
> released, that's not a bug, and the issue should be marked as such and
> should not show up on the release notes
> * it it was something else then we should be documenting the new feature
> via a JIRA
>
> A final issue.
>
> When you are running a release build, release:perform does not produce
> idempotent artifacts.
>
> Just take a look at virtually any random artifact produced by Maven:
>
> $ unzip -c ~/Downloads/maven-dependency-tree-2.2.jar
>> META-INF/maven/org.apache.maven.shared/maven-dependency-tree/pom.properties
>> Archive: /Users/stephenc/Downloads/maven-dependency-tree-2.2.jar
>> inflating:
>> META-INF/maven/org.apache.maven.shared/maven-dependency-tree/pom.properties
>>
>> #Generated by Maven
>> #Sun Sep 14 20:07:30 CEST 2014
>> version=2.2
>> groupId=org.apache.maven.shared
>> artifactId=maven-dependency-tree
>
>
> Now that is just one file where the content is dependent on the date of
> creation. We also have timestamps of different files that are in there
> and
> make each .jar file different... And that is before we even get as far as
> which JDK was used to compile, etc.
>
> A long long time ago I remember a project I was working on where we would
> touch all the compiled binaries to have the last modified time of the
> newest source that contributed to them (and the Makefile was one of those
> sources too BTW) the result of this was that you could check out the code
> on any machine (which would apply the source file timestamps) and rebuild
> the artifact using the same toolchain and end up with the *exact same*
> (bit
> for bit) binary.
>
> The JDK does not give us the tools to have that luxury, so I am not
> saying
> that we should try and reverse engineer a similar effect... rather
>
> When I am releasing stuff and the release:perform goes wrong, as a
> release
> manager, I really just want to burn that version number and use a new
> one.
> Yes the staging repo is helpful, but I need to worry about my own local
> repo having mixed builds... and this same worry crops up for those broken
> builds that need `clean install` as preparationGoals... in fact its worse
> for them because if they need `clean install` then likely they are
> pulling
> things out of order from the local repo and thus within my release
> artifacts I may indeed have *equivalent* artifacts claiming to be the
> same
> release but not having a checksum match to the actual released artifacts.
>
> I don't think a release manager only "prefers" new versions... I think a
> much stronger word is needed ;-)
>
> 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.
>>
>
> Well I can agree with that calculation on the assumption that 1) is true.
> I, however, believe 1) is actually false... and thus the trade-off to my
> way of thinking is completely useless.
>
>
>>
>> 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
>>
>
> WHY WHY WHY
>
> why don't we just use buildnumber? (other than users getting confused
> about
> is 3.2.6-12 before or after 3.2.6-7) we have it in our version spec
> anyway
> (i.e. if no leading 0 then it's a build number, if leading 0 then its a
> qualifier)...
>
> oh and any users that are confused by the missing 3.2.4 will be just as
> confused by 3.2.6-03 with a missing 3.2.6-01 and 3.2.6-02
>
>
>
>> 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.
>
>
> Ahh, perhaps here is the argument for being able to skip version 3.2.4
> only
> now being applied to excuse skipping 3.2.6-01 and 3.2.6-02
>
>
>> People will just become accustom to knowing a qualifier is necessary to
>> find the actual version.
>>
>
> Or similarly people could just become accustomed to knowing that we skip
> versions if we think they are no good... and we stick with our 3 part
> version numbers
>
>
>>
>> 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.
>
>
> Seriously? Anyone who reads that something is available from 3.2.4 will
> expect that to be present in 3.2.6... and who's going to pick up 3.2.4
> when
> 3.2.6 is available (and should have more bug fixes, and the feature
> should
> be bedded down more, etc)
>
> "People will just become accustomed to knowing" that if we say it's going
> to be in 3.2.4 and then we release 3.2.6 then it's in 3.2.6
>
>
>> 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.
>
>
> Or maybe "People will just become accustomed"
>
>
>> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Releases, Continuous Delivery and the Future
Posted by Stephen Connolly <st...@gmail.com>.
On 15 December 2014 at 01:29, 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.
>
I have not seen anyone asking what happened to 3.2.0
Similarly I have not seen anyone asking what happened to 3.1.2, 3.1.3,
3.1.4, 3.1.5, 3.1.6, 3.1.7, 3.1.8 or 3.1.9
And also nobody was visible to me about what exactly happened to
3.0.6-3.0.9 inclusive or the vast range of continuous numbers we skipped
before 3.0.0
I seem to recall a few questions about what da f*ck exactly was 2.0.10 and
was it newer than 2.0.4 but, you know what, our users are by and large
reasonably smart people, they can read an answer if we provide one, and the
user community itself can probably sort out explaining where any missing
versions went, especially if we put the explanation on a page on our
website...
So this use case is, to my mind, not really relevant. I think we can divide
our users into two large groups:
a. Those users who have a mandated version of maven that they must use
b. Those users who are happy to use the latest version of maven whatever
that is
There are other groups out there, but I believe that the above two groups
covers at least 80% of our users
A final point on the user community... if we treat our users like idiots,
then that's the kind of users we will get.
I don't know how the rest of you feel about our users, but I know that our
users are by and large a reasonably smart group of people.
I just plain do not buy this argument about users expecting contiguous
increasing versions.
I think users expect us to actually cut releases on a reasonably frequent
basis and to fix things and generally not make things worse... and that we
will have a page somewhere that is easy to find (probably called release
history) that will let them track down when the thing they care about right
now changed so that they can either fix or roll-back to Get Things Done™
> 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.
>
This applies to core... but not so for testing plugins. We are not just a
project about core. If we decide on a policy it should be a policy that
works for both core and plugins.
One thing we always complain about is the lack of testing in areas where
our automated tests are weak.
To combat that we need to grow our pool of testers to include people from
the user community right now.
Those users may not be as comfortable ensuring that they have cleared out
their local repo of any side artifacts pulled in when testing a staged
release...
If they know that the artifact version number will never be re-used it
gives them a bit more confidence.
And this is not just about testing on your local machine, you might push
the changes to your CI server via a pull request and a pull request builder
to get even better test coverage. Then you have to worry that the CI server
will have some build slaves with old pre-release versions.
If we want to grow testing then I see re-use of versions a complete no-no.
>
> 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.
>
Again, from this use case I see re-use of versions as a complete no-no also.
>
> 4) The release manager case prefers new versions.
When something is found wrong in 3.2.4 during voting, a user will create an
issue in JIRA... found in 3.2.4... so we go and fix it... in 3.2.4... that
just feels messy to me. I much rather say that an issue found in 3.2.4 is
fixed in a later version...
And before anyone asks, if the regression/issue was found in 3.2.4-SNAPSHOT
and we don't want to have -SNAPSHOT versions in JIRA then the
regression/issue gets fixed before the actual 3.2.4 gets released and the
JIRA issue needs to be reclassified...
* if it was a regression and we fix that before the regression gets
released, that's not a bug, and the issue should be marked as such and
should not show up on the release notes
* it it was something else then we should be documenting the new feature
via a JIRA
A final issue.
When you are running a release build, release:perform does not produce
idempotent artifacts.
Just take a look at virtually any random artifact produced by Maven:
$ unzip -c ~/Downloads/maven-dependency-tree-2.2.jar
> META-INF/maven/org.apache.maven.shared/maven-dependency-tree/pom.properties
> Archive: /Users/stephenc/Downloads/maven-dependency-tree-2.2.jar
> inflating:
> META-INF/maven/org.apache.maven.shared/maven-dependency-tree/pom.properties
>
> #Generated by Maven
> #Sun Sep 14 20:07:30 CEST 2014
> version=2.2
> groupId=org.apache.maven.shared
> artifactId=maven-dependency-tree
Now that is just one file where the content is dependent on the date of
creation. We also have timestamps of different files that are in there and
make each .jar file different... And that is before we even get as far as
which JDK was used to compile, etc.
A long long time ago I remember a project I was working on where we would
touch all the compiled binaries to have the last modified time of the
newest source that contributed to them (and the Makefile was one of those
sources too BTW) the result of this was that you could check out the code
on any machine (which would apply the source file timestamps) and rebuild
the artifact using the same toolchain and end up with the *exact same* (bit
for bit) binary.
The JDK does not give us the tools to have that luxury, so I am not saying
that we should try and reverse engineer a similar effect... rather
When I am releasing stuff and the release:perform goes wrong, as a release
manager, I really just want to burn that version number and use a new one.
Yes the staging repo is helpful, but I need to worry about my own local
repo having mixed builds... and this same worry crops up for those broken
builds that need `clean install` as preparationGoals... in fact its worse
for them because if they need `clean install` then likely they are pulling
things out of order from the local repo and thus within my release
artifacts I may indeed have *equivalent* artifacts claiming to be the same
release but not having a checksum match to the actual released artifacts.
I don't think a release manager only "prefers" new versions... I think a
much stronger word is needed ;-)
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.
>
Well I can agree with that calculation on the assumption that 1) is true.
I, however, believe 1) is actually false... and thus the trade-off to my
way of thinking is completely useless.
>
> 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
>
WHY WHY WHY
why don't we just use buildnumber? (other than users getting confused about
is 3.2.6-12 before or after 3.2.6-7) we have it in our version spec anyway
(i.e. if no leading 0 then it's a build number, if leading 0 then its a
qualifier)...
oh and any users that are confused by the missing 3.2.4 will be just as
confused by 3.2.6-03 with a missing 3.2.6-01 and 3.2.6-02
> 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.
Ahh, perhaps here is the argument for being able to skip version 3.2.4 only
now being applied to excuse skipping 3.2.6-01 and 3.2.6-02
> People will just become accustom to knowing a qualifier is necessary to
> find the actual version.
>
Or similarly people could just become accustomed to knowing that we skip
versions if we think they are no good... and we stick with our 3 part
version numbers
>
> 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.
Seriously? Anyone who reads that something is available from 3.2.4 will
expect that to be present in 3.2.6... and who's going to pick up 3.2.4 when
3.2.6 is available (and should have more bug fixes, and the feature should
be bedded down more, etc)
"People will just become accustomed to knowing" that if we say it's going
to be in 3.2.4 and then we release 3.2.6 then it's in 3.2.6
> 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.
Or maybe "People will just become accustomed"
> 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
>
>
>
>
>
>
>
>
>
>
Re: Releases, Continuous Delivery and the Future
Posted by Jason van Zyl <ja...@takari.io>.
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 <wi...@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 <he...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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
Re: Releases, Continuous Delivery and the Future
Posted by William Ferguson <wi...@xandar.com.au>.
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 <he...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Releases, Continuous Delivery and the Future
Posted by Hervé BOUTEMY <he...@free.fr>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Releases, Continuous Delivery and the Future
Posted by Hervé BOUTEMY <he...@free.fr>.
Le vendredi 2 janvier 2015 10:31:52 Baptiste Mathus a écrit :
> Well, I for one find the x.y.z-nn somehow unusual. I'd prefer something
> simple like x.y.z and I don't give a f*ck if some numbers are skipped.
>
> +1 with Stephen: I've never seen someone complain about missing versions
> neither on ML nor IRL. Sure, I suppose people might wonder where the 4.x
> went if the next mvn version was to be 5.0, but apart (and even though)
> from the major version, I don't see any developer ever complaining about
> that.
>
> Just then let's indeed have a changelog somewhere just for reference that
> confirms that the x.y.foo was skipped and never released.
see http://maven.apache.org/docs/history.html
the fact that a version was never released is not explictely written, but
since this is the official history...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Releases, Continuous Delivery and the Future
Posted by Baptiste Mathus <ml...@batmat.net>.
Well, I for one find the x.y.z-nn somehow unusual. I'd prefer something
simple like x.y.z and I don't give a f*ck if some numbers are skipped.
+1 with Stephen: I've never seen someone complain about missing versions
neither on ML nor IRL. Sure, I suppose people might wonder where the 4.x
went if the next mvn version was to be 5.0, but apart (and even though)
from the major version, I don't see any developer ever complaining about
that.
Just then let's indeed have a changelog somewhere just for reference that
confirms that the x.y.foo was skipped and never released.
But I'm sure few people will have a look at it and it won't be a concern.
IMO, there are in fact 3 main cases:
1) people stuck with a corp version won't ever deal with that issue and use
what's provided
2) people wanting the latest version, will just go on the website on
download the first link seemingly being the latest one
3) people wanting to do a careful upgrade (certainly most often for the 1/
group, think build/release engineering team) would just carefully read the
release notes to see what bump is safe to do (this is typically what we do
for Jenkins for example)
My 2 cents.
2014-12-28 22:00 GMT+01:00 Brian E. Fox <br...@infinity.nu>:
>
>
> > On Dec 14, 2014, at 8:29 PM, Jason van Zyl <ja...@takari.io> wrote:
> >
> > 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
>
> +1
>
> This really the only viable scheme I've seen used over the years. It's how
> we do it at Sonatype and it's never been an issue that the public version
> is shown with some -build number.
>
> We will want to ensure that only one release version gets published though
> to reduce confusion. Since everything is staged, this should happen
> normally.
>
> For plugins, which are commonly referred to by users in their poms, this
> might turn out to be a problem as it increases the maintenance load but I
> think we start trying it and if there is an issue we go to an alternate
> approach.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
> --
> Baptiste <Batmat> MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
> nbsp;! <de...@maven.apache.org>
>
Re: Releases, Continuous Delivery and the Future
Posted by "Brian E. Fox" <br...@infinity.nu>.
> On Dec 14, 2014, at 8:29 PM, Jason van Zyl <ja...@takari.io> wrote:
>
> 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
+1
This really the only viable scheme I've seen used over the years. It's how we do it at Sonatype and it's never been an issue that the public version is shown with some -build number.
We will want to ensure that only one release version gets published though to reduce confusion. Since everything is staged, this should happen normally.
For plugins, which are commonly referred to by users in their poms, this might turn out to be a problem as it increases the maintenance load but I think we start trying it and if there is an issue we go to an alternate approach.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Releases, Continuous Delivery and the Future
Posted by Robert Patrick <ro...@oracle.com>.
If you need "outside opinions", I would be happy to participate in that meeting... :-)
--
Robert Patrick <ro...@oracle.com>
VP, FMW Platform Engineering, Oracle Corporation
7460 Warren Pkwy, Ste. 300 Office: +1.972.963.2872
Frisco, TX 75034, USA Mobile: +1.469.556.9450
Professional Oracle WebLogic Server
by Robert Patrick, Gregory Nyberg, and Philip Aston
with Josh Bregman and Paul Done
Book Home Page: http://www.wrox.com/
Kindle Version: http://www.amazon.com/
-----Original Message-----
From: Jason van Zyl [mailto:jason@takari.io]
Sent: Monday, December 15, 2014 11:08 AM
To: Maven Developers List
Subject: Re: Releases, Continuous Delivery and the Future
You're not missing anything. The integration we've written essentially replaces much of the internal resolution mechanism with support on the repository side. We currently do not use SNAPSHOTs and we do use ranges for a team of 1500+ developers. It will all be open source but we're not ready to open it yet. We have made all sorts of assumptions in general but some have been shaped by the requirements of the organization we're working for. We're not exactly sure what the POMs should look like but we're moving toward having no versions anywhere in the POMs and using tooling to generated the required POMs on deployment.
At some point, likely in January, I'll try to have a little meetup in the Bay Area to try and shape some of the final requirements. Our target is making it work for our customer but our hope is that this will be a generally applicable model for continuous delivery. I'm also testing this with Facebook's Presto project which is interesting because we basically have the requirement to work with a graph of related projects and release the graph of projects at the same time. We have the additional requirement that ultimately it needs to be consumable by users from Maven Central.
We certainly haven't figured everything out but we're getting there and it's been working in production for 6 months.
On Dec 15, 2014, at 7:06 AM, Robert Patrick <ro...@oracle.com> wrote:
> Sorry for the noise and maybe I am just being stupid but...
>
> This is a constant source of pain for us as Maven users when we do not use snapshots. The real problem is that once you go down his path, Maven seems to really only have two choices when you set your dependency version to 2.5.3:
>
> 1.) it only matches exactly with version 2.5.3
> 2.) it matches with any version that starts with 2.5.3 and picks "the newest".
>
> Currently, #2 isn't possible without the use of version ranges, which are particularly painful with a large development team where I end up downloading the POM for every version of the artifact listed in maven-metadata.xml (in our case, hundreds per artifact) that is not currently cached in my .m2/repository directory. It seems like the current state of the art is to use the versions plugin to constant update your POM's dependency versions, which works ok but requires extra effort/discipline. Moving Maven core to use #2 seems like it removes the ability (or at least makes it much more difficult) to get repeatable builds.
>
> What am I missing?
>
> Robert Patrick <ro...@oracle.com> VP, FMW Platform
> Engineering Oracle
> Mobile: +1 469 556 9450
> Sent from my iPad
>
>> On Dec 15, 2014, at 12:49 AM, Kristian Rosenvold <kr...@gmail.com> wrote:
>>
>> I somehow think we need to decide if we want to change anything :)
>>
>> Without changing anything there seem to be only "so" many approaches
>> out there, this is well known territory. While initially confusing,
>> jetty's 9.2.3.v20140905 approach is quite good. I assume they might
>> have had a failing " 9.2.3.v20140902" a few days before that we never
>> got to see. It still gives the silly suffix on the name, and I think
>> we might do one better.
>>
>> We change something in maven core, introduce a clearer separation of
>> dependency-version (as-referenced version ) and artifact version:
>> (Using the currently staged assembly-plugin 2.5.3 at
>> https://repository.apache.org/content/repositories/maven-1103 as en
>> example)
>>
>> The artifact is *always* called 2.5.3 in the pom version (what we all
>> know as artifact-version). It's even deployed to these GAV
>> coordinates in staging nexus. The signature signs a 2.5.3. version.
>> In the vote mail we refer to the version as 2.5.3.v2014-12-13.
>>
>> Seeing this version number, maven 3.3+ writes download the artifacts
>> to the folder
>>
>> ~/.m2/repository/org/apache/maven/plugins/maven-assembly-plugin/2.5.3
>> .v2014-12-13
>>
>> The tester tests a version named 2.5.3.v2014-12-13. If I re-roll the
>> version will be 2.5.3.v2014-12-15. The payload is always version
>> 2.5.3.
>>
>> If the 2.5.3.v2014-12-13 is broken, the stage at
>> https://repository.apache.org/content/repositories/maven-1103 is
>> dropped and all the testers/integrators are left with a broken
>> ~/.m2/repository/org/apache/maven/plugins/maven-assembly-plugin/2.5.3
>> .v2014-12-13
>> artifact, waiting for a replacement.
>>
>> Testers with pervious maven versions would have to follow the "old" rules.
>>
>> Does this blend ?
>>
>> (I have not entirely sorted out how this differs from fixing problems
>> with snapshots and using numbered snapshots instead. )
>>
>> Kristian
>>
>>
>>
>> Sat Dec 13 08:35:33
>>
>> 2014-12-15 2:29 GMT+01:00 Jason van Zyl <ja...@takari.io>:
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
>> additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------
Three people can keep a secret provided two of them are dead.
-- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Releases, Continuous Delivery and the Future
Posted by Jason van Zyl <ja...@takari.io>.
You're not missing anything. The integration we've written essentially replaces much of the internal resolution mechanism with support on the repository side. We currently do not use SNAPSHOTs and we do use ranges for a team of 1500+ developers. It will all be open source but we're not ready to open it yet. We have made all sorts of assumptions in general but some have been shaped by the requirements of the organization we're working for. We're not exactly sure what the POMs should look like but we're moving toward having no versions anywhere in the POMs and using tooling to generated the required POMs on deployment.
At some point, likely in January, I'll try to have a little meetup in the Bay Area to try and shape some of the final requirements. Our target is making it work for our customer but our hope is that this will be a generally applicable model for continuous delivery. I'm also testing this with Facebook's Presto project which is interesting because we basically have the requirement to work with a graph of related projects and release the graph of projects at the same time. We have the additional requirement that ultimately it needs to be consumable by users from Maven Central.
We certainly haven't figured everything out but we're getting there and it's been working in production for 6 months.
On Dec 15, 2014, at 7:06 AM, Robert Patrick <ro...@oracle.com> wrote:
> Sorry for the noise and maybe I am just being stupid but...
>
> This is a constant source of pain for us as Maven users when we do not use snapshots. The real problem is that once you go down his path, Maven seems to really only have two choices when you set your dependency version to 2.5.3:
>
> 1.) it only matches exactly with version 2.5.3
> 2.) it matches with any version that starts with 2.5.3 and picks "the newest".
>
> Currently, #2 isn't possible without the use of version ranges, which are particularly painful with a large development team where I end up downloading the POM for every version of the artifact listed in maven-metadata.xml (in our case, hundreds per artifact) that is not currently cached in my .m2/repository directory. It seems like the current state of the art is to use the versions plugin to constant update your POM's dependency versions, which works ok but requires extra effort/discipline. Moving Maven core to use #2 seems like it removes the ability (or at least makes it much more difficult) to get repeatable builds.
>
> What am I missing?
>
> Robert Patrick <ro...@oracle.com>
> VP, FMW Platform Engineering
> Oracle
> Mobile: +1 469 556 9450
> Sent from my iPad
>
>> On Dec 15, 2014, at 12:49 AM, Kristian Rosenvold <kr...@gmail.com> wrote:
>>
>> I somehow think we need to decide if we want to change anything :)
>>
>> Without changing anything there seem to be only "so" many approaches
>> out there, this is well known territory. While initially confusing,
>> jetty's 9.2.3.v20140905 approach is quite good. I assume they might
>> have had a failing " 9.2.3.v20140902" a few days before that we never
>> got to see. It still gives the silly suffix on the name, and I think
>> we might do one better.
>>
>> We change something in maven core, introduce a clearer separation of
>> dependency-version (as-referenced version ) and artifact version:
>> (Using the currently staged assembly-plugin 2.5.3 at
>> https://repository.apache.org/content/repositories/maven-1103 as en
>> example)
>>
>> The artifact is *always* called 2.5.3 in the pom version (what we all
>> know as artifact-version). It's even deployed to these GAV coordinates
>> in staging nexus. The signature signs a 2.5.3. version. In the vote
>> mail we refer to the version as 2.5.3.v2014-12-13.
>>
>> Seeing this version number, maven 3.3+ writes download the artifacts
>> to the folder
>>
>> ~/.m2/repository/org/apache/maven/plugins/maven-assembly-plugin/2.5.3.v2014-12-13
>>
>> The tester tests a version named 2.5.3.v2014-12-13. If I re-roll the
>> version will be 2.5.3.v2014-12-15. The payload is always version
>> 2.5.3.
>>
>> If the 2.5.3.v2014-12-13 is broken, the stage at
>> https://repository.apache.org/content/repositories/maven-1103 is
>> dropped and all the testers/integrators are left with a broken
>> ~/.m2/repository/org/apache/maven/plugins/maven-assembly-plugin/2.5.3.v2014-12-13
>> artifact, waiting for a replacement.
>>
>> Testers with pervious maven versions would have to follow the "old" rules.
>>
>> Does this blend ?
>>
>> (I have not entirely sorted out how this differs from fixing problems
>> with snapshots and using numbered snapshots instead. )
>>
>> Kristian
>>
>>
>>
>> Sat Dec 13 08:35:33
>>
>> 2014-12-15 2:29 GMT+01:00 Jason van Zyl <ja...@takari.io>:
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------
Three people can keep a secret provided two of them are dead.
-- Benjamin Franklin
Re: Releases, Continuous Delivery and the Future
Posted by Robert Patrick <ro...@oracle.com>.
Sorry for the noise and maybe I am just being stupid but...
This is a constant source of pain for us as Maven users when we do not use snapshots. The real problem is that once you go down his path, Maven seems to really only have two choices when you set your dependency version to 2.5.3:
1.) it only matches exactly with version 2.5.3
2.) it matches with any version that starts with 2.5.3 and picks "the newest".
Currently, #2 isn't possible without the use of version ranges, which are particularly painful with a large development team where I end up downloading the POM for every version of the artifact listed in maven-metadata.xml (in our case, hundreds per artifact) that is not currently cached in my .m2/repository directory. It seems like the current state of the art is to use the versions plugin to constant update your POM's dependency versions, which works ok but requires extra effort/discipline. Moving Maven core to use #2 seems like it removes the ability (or at least makes it much more difficult) to get repeatable builds.
What am I missing?
Robert Patrick <ro...@oracle.com>
VP, FMW Platform Engineering
Oracle
Mobile: +1 469 556 9450
Sent from my iPad
> On Dec 15, 2014, at 12:49 AM, Kristian Rosenvold <kr...@gmail.com> wrote:
>
> I somehow think we need to decide if we want to change anything :)
>
> Without changing anything there seem to be only "so" many approaches
> out there, this is well known territory. While initially confusing,
> jetty's 9.2.3.v20140905 approach is quite good. I assume they might
> have had a failing " 9.2.3.v20140902" a few days before that we never
> got to see. It still gives the silly suffix on the name, and I think
> we might do one better.
>
> We change something in maven core, introduce a clearer separation of
> dependency-version (as-referenced version ) and artifact version:
> (Using the currently staged assembly-plugin 2.5.3 at
> https://repository.apache.org/content/repositories/maven-1103 as en
> example)
>
> The artifact is *always* called 2.5.3 in the pom version (what we all
> know as artifact-version). It's even deployed to these GAV coordinates
> in staging nexus. The signature signs a 2.5.3. version. In the vote
> mail we refer to the version as 2.5.3.v2014-12-13.
>
> Seeing this version number, maven 3.3+ writes download the artifacts
> to the folder
>
> ~/.m2/repository/org/apache/maven/plugins/maven-assembly-plugin/2.5.3.v2014-12-13
>
> The tester tests a version named 2.5.3.v2014-12-13. If I re-roll the
> version will be 2.5.3.v2014-12-15. The payload is always version
> 2.5.3.
>
> If the 2.5.3.v2014-12-13 is broken, the stage at
> https://repository.apache.org/content/repositories/maven-1103 is
> dropped and all the testers/integrators are left with a broken
> ~/.m2/repository/org/apache/maven/plugins/maven-assembly-plugin/2.5.3.v2014-12-13
> artifact, waiting for a replacement.
>
> Testers with pervious maven versions would have to follow the "old" rules.
>
> Does this blend ?
>
> (I have not entirely sorted out how this differs from fixing problems
> with snapshots and using numbered snapshots instead. )
>
> Kristian
>
>
>
> Sat Dec 13 08:35:33
>
> 2014-12-15 2:29 GMT+01:00 Jason van Zyl <ja...@takari.io>:
>> 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Releases, Continuous Delivery and the Future
Posted by Jason van Zyl <ja...@takari.io>.
On Dec 15, 2014, at 1:49 AM, Kristian Rosenvold <kr...@gmail.com> wrote:
> I somehow think we need to decide if we want to change anything :)
>
We certainly don't have to. I'm describing a system that's been implemented and it's working but I'm not expecting as a certainty that it's integrated here. I believe it's necessary which is why we built it for a customer.
> Without changing anything there seem to be only "so" many approaches
> out there, this is well known territory. While initially confusing,
> jetty's 9.2.3.v20140905 approach is quite good. I assume they might
> have had a failing " 9.2.3.v20140902" a few days before that we never
> got to see. It still gives the silly suffix on the name, and I think
> we might do one better.
>
The qualifier usually incorporates some temporal aspect and you just pick a build along the continuum that is deemed fit for release.
> We change something in maven core, introduce a clearer separation of
> dependency-version (as-referenced version ) and artifact version:
> (Using the currently staged assembly-plugin 2.5.3 at
> https://repository.apache.org/content/repositories/maven-1103 as en
> example)
>
> The artifact is *always* called 2.5.3 in the pom version (what we all
> know as artifact-version). It's even deployed to these GAV coordinates
> in staging nexus. The signature signs a 2.5.3. version. In the vote
> mail we refer to the version as 2.5.3.v2014-12-13.
>
> Seeing this version number, maven 3.3+ writes download the artifacts
> to the folder
>
> ~/.m2/repository/org/apache/maven/plugins/maven-assembly-plugin/2.5.3.v2014-12-13
>
> The tester tests a version named 2.5.3.v2014-12-13. If I re-roll the
> version will be 2.5.3.v2014-12-15. The payload is always version
> 2.5.3.
>
No, the 2.5.3 version in your case is only the marketing version in what I described. All artifacts that are part of the deployment are fully qualified and have the full version contained within them. This is for a simple deployment. It's get more complicated when you are trying to release a graph of related projects.
> If the 2.5.3.v2014-12-13 is broken, the stage at
> https://repository.apache.org/content/repositories/maven-1103 is
> dropped and all the testers/integrators are left with a broken
> ~/.m2/repository/org/apache/maven/plugins/maven-assembly-plugin/2.5.3.v2014-12-13
> artifact, waiting for a replacement.
>
Sure, it's broken but I am assuming all references to its use are versioned and they will just have to move ahead to try it which means specifying an exact version.
> Testers with pervious maven versions would have to follow the "old" rules.
>
Not sure what you mean by the old rules. The failed version is just discarded, testers use a new version and carry on. Though there is a distinction between using something like a Maven distribution vs a library. If a library build failed then a tester is going to have to update the version they are using. I don't think there is any magic that is sufficient, or desirable, that lets people reuse a version in any form.
> Does this blend ?
>
I think the only point I can see where I don't agree is that the payload always gets the marketing version. I don't think that works.
> (I have not entirely sorted out how this differs from fixing problems
> with snapshots and using numbered snapshots instead. )
>
> Kristian
>
>
>
> Sat Dec 13 08:35:33
>
> 2014-12-15 2:29 GMT+01:00 Jason van Zyl <ja...@takari.io>:
>> 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------
A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.
-- Jakob Burckhardt
Re: Releases, Continuous Delivery and the Future
Posted by Kristian Rosenvold <kr...@gmail.com>.
I somehow think we need to decide if we want to change anything :)
Without changing anything there seem to be only "so" many approaches
out there, this is well known territory. While initially confusing,
jetty's 9.2.3.v20140905 approach is quite good. I assume they might
have had a failing " 9.2.3.v20140902" a few days before that we never
got to see. It still gives the silly suffix on the name, and I think
we might do one better.
We change something in maven core, introduce a clearer separation of
dependency-version (as-referenced version ) and artifact version:
(Using the currently staged assembly-plugin 2.5.3 at
https://repository.apache.org/content/repositories/maven-1103 as en
example)
The artifact is *always* called 2.5.3 in the pom version (what we all
know as artifact-version). It's even deployed to these GAV coordinates
in staging nexus. The signature signs a 2.5.3. version. In the vote
mail we refer to the version as 2.5.3.v2014-12-13.
Seeing this version number, maven 3.3+ writes download the artifacts
to the folder
~/.m2/repository/org/apache/maven/plugins/maven-assembly-plugin/2.5.3.v2014-12-13
The tester tests a version named 2.5.3.v2014-12-13. If I re-roll the
version will be 2.5.3.v2014-12-15. The payload is always version
2.5.3.
If the 2.5.3.v2014-12-13 is broken, the stage at
https://repository.apache.org/content/repositories/maven-1103 is
dropped and all the testers/integrators are left with a broken
~/.m2/repository/org/apache/maven/plugins/maven-assembly-plugin/2.5.3.v2014-12-13
artifact, waiting for a replacement.
Testers with pervious maven versions would have to follow the "old" rules.
Does this blend ?
(I have not entirely sorted out how this differs from fixing problems
with snapshots and using numbered snapshots instead. )
Kristian
Sat Dec 13 08:35:33
2014-12-15 2:29 GMT+01:00 Jason van Zyl <ja...@takari.io>:
> 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
>
>
>
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Releases, Continuous Delivery and the Future
Posted by Fred Cooke <fr...@gmail.com>.
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 <fr...@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
>
>
>
>
>
>
>
>
>
>
Re: Releases, Continuous Delivery and the Future
Posted by Jason van Zyl <ja...@takari.io>.
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 <fr...@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
Re: Releases, Continuous Delivery and the Future
Posted by Fred Cooke <fr...@gmail.com>.
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
>
>
>
>
>
>
>
>
>
>