[DISCUSS] [VOTE] Should we respin CANCELLED releases with the same version number?
Moving discussion off the vote thread The issue with that is when using the Maven Release Plugin, you will not be voting on the released artifacts if you call it x.y.z-RCn, so you would need a whole new vote for x.y.z. We could go all Eclipse nutjob and force the timestamp into every release, e.g. 3.1.0.v20130529 But that way madness lies in my view... In any case, we will see where the vote goes... and if there is a non-definitive answer, e.g. (-3 ∑ binding votes 3) then we can see what alternatives fall out of the mix. On 29 May 2013 12:10, Gary Gregory garydgreg...@gmail.com wrote: FWIW, over in Apache Commons land this is how we handle things. When we prepare and tag a release for version x.y.z, it is tagged as .../x.y.z-RC1. If the [vote] passes, the tag is copied to .../x.y.z. If the [vote] fails, the tag stays as a record of what happened and the email archives tell the story of why the vote failed. The next attempt is tagged as .../x.y.z-RC2, and so on. Some of this is detailed here https://wiki.apache.org/commons/UsingNexusand here https://commons.apache.org/releases/prepare.html Gary On Wed, May 29, 2013 at 6:01 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We have been using a policy of only making releases without skipping version numbers, e.g. 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc Whereby if there is something wrong with the artifacts staged for release, we drop the staging repo, delete the tag, roll back the version, and run again. This vote is to change the policy to: drop the staging repo, document the release as not released, and run with the next version. Under this new proposal, if the staged artifacts for 3.1.0 fail to meet the release criteria, then the artifacts would be dropped from the staging repository and never see the light of day. The tag would remain in SCM, and we would document (somewhere) that the release was cancelled. The respin would have version number 3.1.1 and there would never be a 3.1.0. This change could mean that the first actual release of 3.1.x might end up being 3.1.67 (though I personally view that as unlikely, and in the context of 3.1.x I think we are very nearly there) Please Note: http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes not actually specify what it means by the process will need to be restarted so this vote will effect a change either outcome +1: Never respin with the same version number, always increment the version for a respin 0: Don't care -1: Always respin with the same version number until that version number gets released This vote will be open for 72 hours. A Majority of PMC votes greater that 3 will be deemed as decisive in either direction (i.e. if the sum is -3 or +3 then there is a documented result) For any releases in progress at this point in time, it is up to the release manager to decide what to do if they need to do a respin. -Stephen -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [DISCUSS] [VOTE] Should we respin CANCELLED releases with the same version number?
On Wed, May 29, 2013 at 7:23 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Moving discussion off the vote thread The issue with that is when using the Maven Release Plugin, you will not be voting on the released artifacts if you call it x.y.z-RCn, so you would need a whole new vote for x.y.z. The /[vote]/ and the /SVN tag/ are called x.y.z-RCn, the artifacts in the Nexus staging repo are marked x.y.z. Gary We could go all Eclipse nutjob and force the timestamp into every release, e.g. 3.1.0.v20130529 But that way madness lies in my view... In any case, we will see where the vote goes... and if there is a non-definitive answer, e.g. (-3 ∑ binding votes 3) then we can see what alternatives fall out of the mix. On 29 May 2013 12:10, Gary Gregory garydgreg...@gmail.com wrote: FWIW, over in Apache Commons land this is how we handle things. When we prepare and tag a release for version x.y.z, it is tagged as .../x.y.z-RC1. If the [vote] passes, the tag is copied to .../x.y.z. If the [vote] fails, the tag stays as a record of what happened and the email archives tell the story of why the vote failed. The next attempt is tagged as .../x.y.z-RC2, and so on. Some of this is detailed here https://wiki.apache.org/commons/UsingNexusand here https://commons.apache.org/releases/prepare.html Gary On Wed, May 29, 2013 at 6:01 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We have been using a policy of only making releases without skipping version numbers, e.g. 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc Whereby if there is something wrong with the artifacts staged for release, we drop the staging repo, delete the tag, roll back the version, and run again. This vote is to change the policy to: drop the staging repo, document the release as not released, and run with the next version. Under this new proposal, if the staged artifacts for 3.1.0 fail to meet the release criteria, then the artifacts would be dropped from the staging repository and never see the light of day. The tag would remain in SCM, and we would document (somewhere) that the release was cancelled. The respin would have version number 3.1.1 and there would never be a 3.1.0. This change could mean that the first actual release of 3.1.x might end up being 3.1.67 (though I personally view that as unlikely, and in the context of 3.1.x I think we are very nearly there) Please Note: http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes not actually specify what it means by the process will need to be restarted so this vote will effect a change either outcome +1: Never respin with the same version number, always increment the version for a respin 0: Don't care -1: Always respin with the same version number until that version number gets released This vote will be open for 72 hours. A Majority of PMC votes greater that 3 will be deemed as decisive in either direction (i.e. if the sum is -3 or +3 then there is a documented result) For any releases in progress at this point in time, it is up to the release manager to decide what to do if they need to do a respin. -Stephen -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [DISCUSS] [VOTE] Should we respin CANCELLED releases with the same version number?
Ahh, so that is just a nicer way of handling the respin with same version number. In any case we currently have a ∑ binding = 0 so no decision forthcoming yet... but early days ;-) On 29 May 2013 12:31, Gary Gregory garydgreg...@gmail.com wrote: On Wed, May 29, 2013 at 7:23 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Moving discussion off the vote thread The issue with that is when using the Maven Release Plugin, you will not be voting on the released artifacts if you call it x.y.z-RCn, so you would need a whole new vote for x.y.z. The /[vote]/ and the /SVN tag/ are called x.y.z-RCn, the artifacts in the Nexus staging repo are marked x.y.z. Gary We could go all Eclipse nutjob and force the timestamp into every release, e.g. 3.1.0.v20130529 But that way madness lies in my view... In any case, we will see where the vote goes... and if there is a non-definitive answer, e.g. (-3 ∑ binding votes 3) then we can see what alternatives fall out of the mix. On 29 May 2013 12:10, Gary Gregory garydgreg...@gmail.com wrote: FWIW, over in Apache Commons land this is how we handle things. When we prepare and tag a release for version x.y.z, it is tagged as .../x.y.z-RC1. If the [vote] passes, the tag is copied to .../x.y.z. If the [vote] fails, the tag stays as a record of what happened and the email archives tell the story of why the vote failed. The next attempt is tagged as .../x.y.z-RC2, and so on. Some of this is detailed here https://wiki.apache.org/commons/UsingNexusand here https://commons.apache.org/releases/prepare.html Gary On Wed, May 29, 2013 at 6:01 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We have been using a policy of only making releases without skipping version numbers, e.g. 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc Whereby if there is something wrong with the artifacts staged for release, we drop the staging repo, delete the tag, roll back the version, and run again. This vote is to change the policy to: drop the staging repo, document the release as not released, and run with the next version. Under this new proposal, if the staged artifacts for 3.1.0 fail to meet the release criteria, then the artifacts would be dropped from the staging repository and never see the light of day. The tag would remain in SCM, and we would document (somewhere) that the release was cancelled. The respin would have version number 3.1.1 and there would never be a 3.1.0. This change could mean that the first actual release of 3.1.x might end up being 3.1.67 (though I personally view that as unlikely, and in the context of 3.1.x I think we are very nearly there) Please Note: http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes not actually specify what it means by the process will need to be restarted so this vote will effect a change either outcome +1: Never respin with the same version number, always increment the version for a respin 0: Don't care -1: Always respin with the same version number until that version number gets released This vote will be open for 72 hours. A Majority of PMC votes greater that 3 will be deemed as decisive in either direction (i.e. if the sum is -3 or +3 then there is a documented result) For any releases in progress at this point in time, it is up to the release manager to decide what to do if they need to do a respin. -Stephen -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [DISCUSS] [VOTE] Should we respin CANCELLED releases with the same version number?
It seems that most people care about X.Y and X.Y.Z numbers of the versioning scheme, not X.Y.Z.N. To spin through version numbers without concern during release candidates, perhaps using the 4th position, N, would then allow continued use of the familiar X.Y and X.Y.Z references? Major.Minor.Point/bug.RC. It's arbitrary precision, but maintains the X.Y.Z format, and Z doesn't have skipped numbers. On Wed, May 29, 2013 at 6:31 AM, Gary Gregory garydgreg...@gmail.comwrote: On Wed, May 29, 2013 at 7:23 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Moving discussion off the vote thread The issue with that is when using the Maven Release Plugin, you will not be voting on the released artifacts if you call it x.y.z-RCn, so you would need a whole new vote for x.y.z. The /[vote]/ and the /SVN tag/ are called x.y.z-RCn, the artifacts in the Nexus staging repo are marked x.y.z. Gary We could go all Eclipse nutjob and force the timestamp into every release, e.g. 3.1.0.v20130529 But that way madness lies in my view... In any case, we will see where the vote goes... and if there is a non-definitive answer, e.g. (-3 ∑ binding votes 3) then we can see what alternatives fall out of the mix. On 29 May 2013 12:10, Gary Gregory garydgreg...@gmail.com wrote: FWIW, over in Apache Commons land this is how we handle things. When we prepare and tag a release for version x.y.z, it is tagged as .../x.y.z-RC1. If the [vote] passes, the tag is copied to .../x.y.z. If the [vote] fails, the tag stays as a record of what happened and the email archives tell the story of why the vote failed. The next attempt is tagged as .../x.y.z-RC2, and so on. Some of this is detailed here https://wiki.apache.org/commons/UsingNexusand here https://commons.apache.org/releases/prepare.html Gary On Wed, May 29, 2013 at 6:01 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We have been using a policy of only making releases without skipping version numbers, e.g. 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc Whereby if there is something wrong with the artifacts staged for release, we drop the staging repo, delete the tag, roll back the version, and run again. This vote is to change the policy to: drop the staging repo, document the release as not released, and run with the next version. Under this new proposal, if the staged artifacts for 3.1.0 fail to meet the release criteria, then the artifacts would be dropped from the staging repository and never see the light of day. The tag would remain in SCM, and we would document (somewhere) that the release was cancelled. The respin would have version number 3.1.1 and there would never be a 3.1.0. This change could mean that the first actual release of 3.1.x might end up being 3.1.67 (though I personally view that as unlikely, and in the context of 3.1.x I think we are very nearly there) Please Note: http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes not actually specify what it means by the process will need to be restarted so this vote will effect a change either outcome +1: Never respin with the same version number, always increment the version for a respin 0: Don't care -1: Always respin with the same version number until that version number gets released This vote will be open for 72 hours. A Majority of PMC votes greater that 3 will be deemed as decisive in either direction (i.e. if the sum is -3 or +3 then there is a documented result) For any releases in progress at this point in time, it is up to the release manager to decide what to do if they need to do a respin. -Stephen -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [DISCUSS] [VOTE] Should we respin CANCELLED releases with the same version number?
I'm totally fine with the 1.0-RC0 1.0-RC1 1.0-RC2 == 1.0 thing, in Git you don't even have to copy anything ;-) If you're going to do trial releases, then RCX is one good way to do it. I've got to point out, though, that skipped numbers means exactly NOTHING :-) You *always* skip numbers, by definition, every time you jump to a new version of a greater number in the next higher slot... eg: 1.1 1.2 1.3 1.4 1.5 1.6 2.0 you missed 1.7 and 1.8, OMG :-p Fred. On Wed, May 29, 2013 at 1:54 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Ahh, so that is just a nicer way of handling the respin with same version number. In any case we currently have a ∑ binding = 0 so no decision forthcoming yet... but early days ;-) On 29 May 2013 12:31, Gary Gregory garydgreg...@gmail.com wrote: On Wed, May 29, 2013 at 7:23 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Moving discussion off the vote thread The issue with that is when using the Maven Release Plugin, you will not be voting on the released artifacts if you call it x.y.z-RCn, so you would need a whole new vote for x.y.z. The /[vote]/ and the /SVN tag/ are called x.y.z-RCn, the artifacts in the Nexus staging repo are marked x.y.z. Gary We could go all Eclipse nutjob and force the timestamp into every release, e.g. 3.1.0.v20130529 But that way madness lies in my view... In any case, we will see where the vote goes... and if there is a non-definitive answer, e.g. (-3 ∑ binding votes 3) then we can see what alternatives fall out of the mix. On 29 May 2013 12:10, Gary Gregory garydgreg...@gmail.com wrote: FWIW, over in Apache Commons land this is how we handle things. When we prepare and tag a release for version x.y.z, it is tagged as .../x.y.z-RC1. If the [vote] passes, the tag is copied to .../x.y.z. If the [vote] fails, the tag stays as a record of what happened and the email archives tell the story of why the vote failed. The next attempt is tagged as .../x.y.z-RC2, and so on. Some of this is detailed here https://wiki.apache.org/commons/UsingNexusand here https://commons.apache.org/releases/prepare.html Gary On Wed, May 29, 2013 at 6:01 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We have been using a policy of only making releases without skipping version numbers, e.g. 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc Whereby if there is something wrong with the artifacts staged for release, we drop the staging repo, delete the tag, roll back the version, and run again. This vote is to change the policy to: drop the staging repo, document the release as not released, and run with the next version. Under this new proposal, if the staged artifacts for 3.1.0 fail to meet the release criteria, then the artifacts would be dropped from the staging repository and never see the light of day. The tag would remain in SCM, and we would document (somewhere) that the release was cancelled. The respin would have version number 3.1.1 and there would never be a 3.1.0. This change could mean that the first actual release of 3.1.x might end up being 3.1.67 (though I personally view that as unlikely, and in the context of 3.1.x I think we are very nearly there) Please Note: http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes not actually specify what it means by the process will need to be restarted so this vote will effect a change either outcome +1: Never respin with the same version number, always increment the version for a respin 0: Don't care -1: Always respin with the same version number until that version number gets released This vote will be open for 72 hours. A Majority of PMC votes greater that 3 will be deemed as decisive in either direction (i.e. if the sum is -3 or +3 then there is a documented result) For any releases in progress at this point in time, it is up to the release manager to decide what to do if they need to do a respin. -Stephen -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/
Re: [DISCUSS] [VOTE] Should we respin CANCELLED releases with the same version number?
On 29 May 2013 20:53, Stephen Connolly stephen.alan.conno...@gmail.com wrote: The issue with that is when using the Maven Release Plugin, you will not be ... Can't we fix the tooling then? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] [VOTE] Should we respin CANCELLED releases with the same version number?
Actually clarified that the release plugin is being used but the tag is being forced to a different name and then moved post successful release, e.g. mvn release:prepate release:perform -DreleaseVersion=3.1.0 -Dtag=3.1.0-RC1 Now there is an issue with that in that the pom will contain the wrong tag in the scm section... $ svn log --limit 5 -v https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.5 r1456364 | bodewig | 2013-03-14 08:43:27 + (Thu, 14 Mar 2013) | 1 line Changed paths: A /commons/proper/compress/tags/COMPRESS-1.5 (from /commons/proper/compress/tags/COMPRESS-1.5_RC1:1456363) Vote has passed, 1.5 is released r1455005 | bodewig | 2013-03-11 06:10:51 + (Mon, 11 Mar 2013) | 1 line Changed paths: A /commons/proper/compress/tags/COMPRESS-1.5_RC1 (from /commons/proper/compress/trunk:1455004) M /commons/proper/compress/tags/COMPRESS-1.5_RC1/pom.xml Tagging first RC for Compress 1.5 So they are not using the release plugin then... perhaps a pseudo-tag option is needed for the release plugin then... On 29 May 2013 13:40, Barrie Treloar baerr...@gmail.com wrote: On 29 May 2013 20:53, Stephen Connolly stephen.alan.conno...@gmail.com wrote: The issue with that is when using the Maven Release Plugin, you will not be ... Can't we fix the tooling then? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] [VOTE] Should we respin CANCELLED releases with the same version number?
You're voting on a set of sources, and the state of them, more than the specific binary built on a specific platform. You're not really voting on the arbitrary binary that manifests itself as a result of those sources and build. Although it's possible to build from the same sources and get a (meaningfully) different binary, the chances of that are slim to none provided the developer is using the same box/dir/tools and the project is configured correctly. This can be handled by convention and discipline. RC releases should be done as full blown releases with no extra flags, tagged and versioned throughout as what they are. Once an RC is accepted, simply adjust the version and release from the commit after the one the last RC came from (with a diff that is purely pom version field change). This is in Git terms. You're talking in SVN terms. These are impl details of the same approach. There are many ways to skin this cat acceptably. The main criteria (in my mind) is that no two binaries are built with the same version number. Rebuilding from the new tag (or just new commit in Git) can be handled by staging that one binary, and simply skipping it if the dev screwed something up. You could also just skip the RC stuff, which is pretty normal in typical maven-built stuff anyway, and never publish bad bins to central resulting in 1.1 1.7 1.24 2.0 in central. Even the matching binaries could be OK if there is a procedure to manually publish the hashes of the artifacts in question in the email announcement such that the intent of the developer can be checked against the reality down stream. Something like I've released 0.1 of XYZ, with jar of hash abcdef123 and pom of hash 123456fedcba. with those hashes differing on the second try (if required). As stated, though, typically not many, if any, tries are required, as plenty of snapshots have been tried, and lots of testing is done on the sources intended to be released. Fred. On Wed, May 29, 2013 at 2:53 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Actually clarified that the release plugin is being used but the tag is being forced to a different name and then moved post successful release, e.g. mvn release:prepate release:perform -DreleaseVersion=3.1.0 -Dtag=3.1.0-RC1 Now there is an issue with that in that the pom will contain the wrong tag in the scm section... $ svn log --limit 5 -v https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.5 r1456364 | bodewig | 2013-03-14 08:43:27 + (Thu, 14 Mar 2013) | 1 line Changed paths: A /commons/proper/compress/tags/COMPRESS-1.5 (from /commons/proper/compress/tags/COMPRESS-1.5_RC1:1456363) Vote has passed, 1.5 is released r1455005 | bodewig | 2013-03-11 06:10:51 + (Mon, 11 Mar 2013) | 1 line Changed paths: A /commons/proper/compress/tags/COMPRESS-1.5_RC1 (from /commons/proper/compress/trunk:1455004) M /commons/proper/compress/tags/COMPRESS-1.5_RC1/pom.xml Tagging first RC for Compress 1.5 So they are not using the release plugin then... perhaps a pseudo-tag option is needed for the release plugin then... On 29 May 2013 13:40, Barrie Treloar baerr...@gmail.com wrote: On 29 May 2013 20:53, Stephen Connolly stephen.alan.conno...@gmail.com wrote: The issue with that is when using the Maven Release Plugin, you will not be ... Can't we fix the tooling then? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] [VOTE] Should we respin CANCELLED releases with the same version number?
-1 for actual releases: it would create more mess imo for end users if there's many bizarre jumps in numbering The thing with this argument is that it's very, very weak. If a missed version confuses a user, they're basically brain-dead. Assuming your users are brain dead is _always_ dangerous. Assuming the users or a _development_ tool are brain-dead is that in and of itself IMO. A random example from central that I gave to Robert earlier: http://search.maven.org/#search|gav|1|g%3A%22antlr%22%20AND%20a%3A%22antlr%22 I don't know about the rest of you... but I'm not confused by the absence of 2.7.3 in any way shape or form. I'm additionally not confused by the absence of 2.7.8, 2.7.9, 2.7.10, etc, nor 2.8.* nor 2.9.* It's meaningless to me that they're absent. I use and test a version (usually latest) and verify it functions adequately for my needs, then I depend on it (dep or plugin equally) and that's it. If I find a flaw, or need to use a new feature, then I can go looking for the best version that is compatible with my setup, that contains it (again, likely latest, API change not withstanding). Being worried about developers being confused by a non-sequential set of binaries to choose from is bizarre at best. Developers, even the bad ones, are generally a fairly intelligent bunch. This is not winamp! :-p (nor VLC) Fred.
Re: [DISCUSS] [VOTE] Should we respin CANCELLED releases with the same version number?
What do we currently do for plugins? What do we currently do for core? Is there in difference in the approach taken? We call for a vot for vX.Y.Z of arbitrary plugin (plugins's [recently at least] do not appear to go throught he beta/RC phases). Can someone please spell out a sequence of events (by time) as to what happens through the entire process? From prep to vote to ending up in central. And the same sequnce, but for a failed vote, and it's revoting (we've used the same version no again, here, have we not?) -Chris On Thu, May 30, 2013 at 6:11 AM, Fred Cooke fred.co...@gmail.com wrote: -1 for actual releases: it would create more mess imo for end users if there's many bizarre jumps in numbering The thing with this argument is that it's very, very weak. If a missed version confuses a user, they're basically brain-dead. Assuming your users are brain dead is _always_ dangerous. Assuming the users or a _development_ tool are brain-dead is that in and of itself IMO. A random example from central that I gave to Robert earlier: http://search.maven.org/#search|gav|1|g%3A%22antlr%22%20AND%20a%3A%22antlr%22 I don't know about the rest of you... but I'm not confused by the absence of 2.7.3 in any way shape or form. I'm additionally not confused by the absence of 2.7.8, 2.7.9, 2.7.10, etc, nor 2.8.* nor 2.9.* It's meaningless to me that they're absent. I use and test a version (usually latest) and verify it functions adequately for my needs, then I depend on it (dep or plugin equally) and that's it. If I find a flaw, or need to use a new feature, then I can go looking for the best version that is compatible with my setup, that contains it (again, likely latest, API change not withstanding). Being worried about developers being confused by a non-sequential set of binaries to choose from is bizarre at best. Developers, even the bad ones, are generally a fairly intelligent bunch. This is not winamp! :-p (nor VLC) Fred.
