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 > > > > > > > > > >
