Re: [RESULT] [VOTE] Versioning after a failed release
On 2/14/11 13:42, Guillaume Nodet wrote: I'm closing this vote with the following results: binding A: Guillaume Nodet, Stuart McCulloch, Karl Pauls, Clément Escoffier non binding A: Jean-Baptiste Onofré, Andreas Pieber, Simon, Alasdair Nottingham, David Jencks, Jeremy Hugues non binding B: Toni Menzel, Sahoo binding B: Felix Mschberger, Marcel Offermans, Carsten Ziegeler The A option seems is favored, but given the number of B votes, I'll update the release process to indicate that the release manager is free to either use a different version or delete the tag and re-create it with the same version. Sounds reasonable to me. Thanks. - richard Thx to everybody ! On Fri, Feb 4, 2011 at 09:50, Guillaume Nodetgno...@gmail.com wrote: Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version The vote will be opened for at least 72 hours. Happy voting! -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Versioning after a failed release
A (non-binding). FWIW: Stuart brought me off the fence. If the first 1.0.x release is 1.0.5 then under semantic versioning guidelines this would mean 5 releases of the bundle at previous micro numbers have already passed which might cause users some confusion, or cause them to ask for an explanation. This confusion persists for ever more. The number of people seeing this admittedly lesser kind of confusion will likely be far greater than the people who use the RC artifacts from a staging repo, who should know better. On 5 February 2011 12:50, Stuart McCulloch mccu...@gmail.com wrote: On 5 February 2011 12:21, Guillaume Nodet gno...@gmail.com wrote: As long has the release has not been approved, the tag does not match an official release, so it can be freely deleted. yep, that's what I meant - another point to consider is users might see 1.0.5 and think it's stable (as it's not 1.0.0) whereas in fact there could have been 5 staged versions just to sort out license / dependency issues and no actual code changes Once the release is voted, I think everyone agree the tag becomes immutable. FWIW, Git is much better as a tag really correspond to a moment in the history, not a branch (which actually makes more sense if you think about it). agreed, git is better in this regard - but it can be hard to understand at times :) On Sat, Feb 5, 2011 at 11:04, Felix Meschberger fmesc...@adobe.com wrote: Hi, Am Samstag, den 05.02.2011, 09:52 + schrieb Sahoo: On Friday 04 February 2011 04:48 PM, Stuart McCulloch wrote: it is easy to retag releases in svn What exactly do you mean by retag releases in svn? Rename an existing tag or using the same tag name to tag a different snapshot of the source code base? Neither should be done in my IMHO. Agreed, both is far too easy ... Regards Felix -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Stuart
Re: [VOTE] Versioning after a failed release
Hi, Just to shed some light from other projects: * In Jackrabbit a tag was created in anticipation of an imminent release 2.2.3. A bug was discovered. The tag was removed and the next release will be 2.2.4 (there will not be a 2.2.3). * In Tomcat they voted on a release and found issues (quality wise) so decided to declare 7.0.7 broken. The version number was not reused and the release currently under vote has the next version 7.0.8. Regards Felix Am Montag, den 07.02.2011, 10:56 + schrieb Jeremy Hughes: A (non-binding). FWIW: Stuart brought me off the fence. If the first 1.0.x release is 1.0.5 then under semantic versioning guidelines this would mean 5 releases of the bundle at previous micro numbers have already passed which might cause users some confusion, or cause them to ask for an explanation. This confusion persists for ever more. The number of people seeing this admittedly lesser kind of confusion will likely be far greater than the people who use the RC artifacts from a staging repo, who should know better. On 5 February 2011 12:50, Stuart McCulloch mccu...@gmail.com wrote: On 5 February 2011 12:21, Guillaume Nodet gno...@gmail.com wrote: As long has the release has not been approved, the tag does not match an official release, so it can be freely deleted. yep, that's what I meant - another point to consider is users might see 1.0.5 and think it's stable (as it's not 1.0.0) whereas in fact there could have been 5 staged versions just to sort out license / dependency issues and no actual code changes Once the release is voted, I think everyone agree the tag becomes immutable. FWIW, Git is much better as a tag really correspond to a moment in the history, not a branch (which actually makes more sense if you think about it). agreed, git is better in this regard - but it can be hard to understand at times :) On Sat, Feb 5, 2011 at 11:04, Felix Meschberger fmesc...@adobe.com wrote: Hi, Am Samstag, den 05.02.2011, 09:52 + schrieb Sahoo: On Friday 04 February 2011 04:48 PM, Stuart McCulloch wrote: it is easy to retag releases in svn What exactly do you mean by retag releases in svn? Rename an existing tag or using the same tag name to tag a different snapshot of the source code base? Neither should be done in my IMHO. Agreed, both is far too easy ... Regards Felix -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Stuart
Re: [VOTE] Versioning after a failed release
On 7 February 2011 19:50, Felix Meschberger fmesc...@adobe.com wrote: Hi, Just to shed some light from other projects: * In Jackrabbit a tag was created in anticipation of an imminent release 2.2.3. A bug was discovered. The tag was removed and the next release will be 2.2.4 (there will not be a 2.2.3). * In Tomcat they voted on a release and found issues (quality wise) so decided to declare 7.0.7 broken. The version number was not reused and the release currently under vote has the next version 7.0.8. which would actually be allowed under option A because it says can reuse, not must (unlike option B) personally I think it's a bad idea to try to create a single rule to cover all possibilities - just leave it to the discretion of the release manager Regards Felix Am Montag, den 07.02.2011, 10:56 + schrieb Jeremy Hughes: A (non-binding). FWIW: Stuart brought me off the fence. If the first 1.0.x release is 1.0.5 then under semantic versioning guidelines this would mean 5 releases of the bundle at previous micro numbers have already passed which might cause users some confusion, or cause them to ask for an explanation. This confusion persists for ever more. The number of people seeing this admittedly lesser kind of confusion will likely be far greater than the people who use the RC artifacts from a staging repo, who should know better. On 5 February 2011 12:50, Stuart McCulloch mccu...@gmail.com wrote: On 5 February 2011 12:21, Guillaume Nodet gno...@gmail.com wrote: As long has the release has not been approved, the tag does not match an official release, so it can be freely deleted. yep, that's what I meant - another point to consider is users might see 1.0.5 and think it's stable (as it's not 1.0.0) whereas in fact there could have been 5 staged versions just to sort out license / dependency issues and no actual code changes Once the release is voted, I think everyone agree the tag becomes immutable. FWIW, Git is much better as a tag really correspond to a moment in the history, not a branch (which actually makes more sense if you think about it). agreed, git is better in this regard - but it can be hard to understand at times :) On Sat, Feb 5, 2011 at 11:04, Felix Meschberger fmesc...@adobe.com wrote: Hi, Am Samstag, den 05.02.2011, 09:52 + schrieb Sahoo: On Friday 04 February 2011 04:48 PM, Stuart McCulloch wrote: it is easy to retag releases in svn What exactly do you mean by retag releases in svn? Rename an existing tag or using the same tag name to tag a different snapshot of the source code base? Neither should be done in my IMHO. Agreed, both is far too easy ... Regards Felix -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Stuart -- Cheers, Stuart
Re: [VOTE] Versioning after a failed release
Hi, [X] A - Releases following a failed release can reuse the same version It took me a while before making my decision. The Felix release process is pretty complex right now and not adding complexity is good. Especially, when you already have a technical release process which is for iPOJO a lot of tests (several Vms, several OSGi implementations, several versions of the configuration admin / event admin...), updating the version (because you forget to update something in the NOTICE file) has a lot of consequences (re-upating the versions, reconfiguring the tests, re-run all tests...). The risk for a user to get a wrong release or more or less limited to people from dev@felix.apache.org, which are somewhat aware of the staging / voting steps. I agree, there is still a risk that somebody checkout the complete Felix Releases from our SVN, build all of them (which probably takes more than 72 hours), and select an ongoing release. I forget the download from a staging repository, because the only way to get the url is inside the [VOTE] mail, which is kind of clear about the status. (I ignore the people downloading the release candidates for testing/checking before sending their vote, who should also be aware of the status of the release). For from my point of view, the issue is quite limited, especially if we reduce the number of rejected releases... I think, the issue with our release process itself: - no way to automate the legal files creation - no way to automate the verification - as we focus on modular projects, the maven release process is hard to use (and so re-cutting a release is painful) So, we should focus on a simplification of the release process or providing tools to make it more 'robust'. At one point of time, I've developed a tiny tools checking a release. It checked the signatures, the presence of the legal files, their content (based on the content of the bundle and the import-packages), the copyright years, the project build-status (mvn clean package), the existence of the tag, and so on. I've stopped the development of this tools because of the new NOTICE/DEPENDENCIES which was unclear at that point of time, and the apparition of multi-module releases which were not supported. But in fact, writing such tools was easy. In addition, Felix has started refactoring our parent pom file to partially automate the generation of legal files, this would be the perfect solution. So, I'm looking forward those progress, and will on my side try to get this tools back to work. Regards, Clement On 04.02.11 09:50, Guillaume Nodet gno...@gmail.com wrote: Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version The vote will be opened for at least 72 hours. Happy voting! -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Versioning after a failed release
My (non-binding) vote is for B. Although nexus provides a staging repo and hence failed releases never reach the official repo, people who try to use the artifact off the staging repo when the vote is active can potentially make their local maven repository inconsistent with what will eventually appear in the release repository. Sahoo On Friday 04 February 2011 02:20 PM, Guillaume Nodet wrote: Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version The vote will be opened for at least 72 hours. Happy voting!
Re: [VOTE] Versioning after a failed release
On Friday 04 February 2011 04:48 PM, Stuart McCulloch wrote: it is easy to retag releases in svn What exactly do you mean by retag releases in svn? Rename an existing tag or using the same tag name to tag a different snapshot of the source code base? Neither should be done in my IMHO. Sahoo
Re: [VOTE] Versioning after a failed release
Hi, Am Samstag, den 05.02.2011, 09:52 + schrieb Sahoo: On Friday 04 February 2011 04:48 PM, Stuart McCulloch wrote: it is easy to retag releases in svn What exactly do you mean by retag releases in svn? Rename an existing tag or using the same tag name to tag a different snapshot of the source code base? Neither should be done in my IMHO. Agreed, both is far too easy ... Regards Felix
Re: [VOTE] Versioning after a failed release
As long has the release has not been approved, the tag does not match an official release, so it can be freely deleted. Once the release is voted, I think everyone agree the tag becomes immutable. FWIW, Git is much better as a tag really correspond to a moment in the history, not a branch (which actually makes more sense if you think about it). On Sat, Feb 5, 2011 at 11:04, Felix Meschberger fmesc...@adobe.com wrote: Hi, Am Samstag, den 05.02.2011, 09:52 + schrieb Sahoo: On Friday 04 February 2011 04:48 PM, Stuart McCulloch wrote: it is easy to retag releases in svn What exactly do you mean by retag releases in svn? Rename an existing tag or using the same tag name to tag a different snapshot of the source code base? Neither should be done in my IMHO. Agreed, both is far too easy ... Regards Felix -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Versioning after a failed release
Agree. Regards JB -Original Message- From: Guillaume Nodet gno...@gmail.com Date: Sat, 5 Feb 2011 13:21:15 To: dev@felix.apache.org Reply-To: dev@felix.apache.org Subject: Re: [VOTE] Versioning after a failed release As long has the release has not been approved, the tag does not match an official release, so it can be freely deleted. Once the release is voted, I think everyone agree the tag becomes immutable. FWIW, Git is much better as a tag really correspond to a moment in the history, not a branch (which actually makes more sense if you think about it). On Sat, Feb 5, 2011 at 11:04, Felix Meschberger fmesc...@adobe.com wrote: Hi, Am Samstag, den 05.02.2011, 09:52 + schrieb Sahoo: On Friday 04 February 2011 04:48 PM, Stuart McCulloch wrote: it is easy to retag releases in svn What exactly do you mean by retag releases in svn? Rename an existing tag or using the same tag name to tag a different snapshot of the source code base? Neither should be done in my IMHO. Agreed, both is far too easy ... Regards Felix -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Versioning after a failed release
On 5 February 2011 12:21, Guillaume Nodet gno...@gmail.com wrote: As long has the release has not been approved, the tag does not match an official release, so it can be freely deleted. yep, that's what I meant - another point to consider is users might see 1.0.5 and think it's stable (as it's not 1.0.0) whereas in fact there could have been 5 staged versions just to sort out license / dependency issues and no actual code changes Once the release is voted, I think everyone agree the tag becomes immutable. FWIW, Git is much better as a tag really correspond to a moment in the history, not a branch (which actually makes more sense if you think about it). agreed, git is better in this regard - but it can be hard to understand at times :) On Sat, Feb 5, 2011 at 11:04, Felix Meschberger fmesc...@adobe.com wrote: Hi, Am Samstag, den 05.02.2011, 09:52 + schrieb Sahoo: On Friday 04 February 2011 04:48 PM, Stuart McCulloch wrote: it is easy to retag releases in svn What exactly do you mean by retag releases in svn? Rename an existing tag or using the same tag name to tag a different snapshot of the source code base? Neither should be done in my IMHO. Agreed, both is far too easy ... Regards Felix -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Stuart
Re: [VOTE] Versioning after a failed release
very much A (non-binding) I don't really see the point in making felix policies incomprehensible to most maven users without really really good reasons. david jencks On Feb 4, 2011, at 12:50 AM, Guillaume Nodet wrote: Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version The vote will be opened for at least 72 hours. Happy voting! -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[VOTE] Versioning after a failed release
Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version The vote will be opened for at least 72 hours. Happy voting! -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Versioning after a failed release
+1 for A. Regards JB On 02/04/2011 09:50 AM, Guillaume Nodet wrote: Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version The vote will be opened for at least 72 hours. Happy voting!
Re: [VOTE] Versioning after a failed release
Hi, B - never reuse version numbers Regards Felix Am Freitag, den 04.02.2011, 08:50 + schrieb Guillaume Nodet: Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version The vote will be opened for at least 72 hours. Happy voting!
Re: [VOTE] Versioning after a failed release
B - Releases following a failed release must use a different version. For me traceability is key. Much more transparent to the user. Toni On Fri, Feb 4, 2011 at 10:05 AM, Felix Meschberger fmesc...@adobe.comwrote: Hi, B - never reuse version numbers Regards Felix Am Freitag, den 04.02.2011, 08:50 + schrieb Guillaume Nodet: Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version The vote will be opened for at least 72 hours. Happy voting! -- *Toni Menzel - http://www.okidokiteam.com*
Re: [VOTE] Versioning after a failed release
I'm voting for B: use different version numbers for each attempt On 4 Feb 2011, at 9:50 , Guillaume Nodet wrote: Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version The vote will be opened for at least 72 hours. Happy voting! -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Versioning after a failed release
A On Fri, Feb 4, 2011 at 09:50, Guillaume Nodet gno...@gmail.com wrote: Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version The vote will be opened for at least 72 hours. Happy voting! -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Versioning after a failed release
B (non-binding) Alasdair Nottingham On 4 Feb 2011, at 09:42, Guillaume Nodet gno...@gmail.com wrote: A On Fri, Feb 4, 2011 at 09:50, Guillaume Nodet gno...@gmail.com wrote: Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version The vote will be opened for at least 72 hours. Happy voting! -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Versioning after a failed release
A (non-binding) kind regards, andreas On Fri, Feb 04, 2011 at 09:50:35AM +0100, Guillaume Nodet wrote: Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version The vote will be opened for at least 72 hours. Happy voting! -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com pgpzdwaqImBAe.pgp Description: PGP signature
Re: [VOTE] Versioning after a failed release
On 4 February 2011 08:50, Guillaume Nodet gno...@gmail.com wrote: Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version +1 for A ... while I understand the reasons behind B, I just don't like the idea of making it mandatory TBH users shouldn't be affected by restaging as the staged binaries never reach Maven central, and it is easy to retag releases in svn The vote will be opened for at least 72 hours. Happy voting! -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Stuart
Re: [VOTE] Versioning after a failed release
[X] B - Releases following a failed release must use a different version Carsten Guillaume Nodet wrote Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version The vote will be opened for at least 72 hours. Happy voting! -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Versioning after a failed release
So far, we are tied. :-) - richard On 2/4/11 3:50, Guillaume Nodet wrote: Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version The vote will be opened for at least 72 hours. Happy voting!
Re: [VOTE] Versioning after a failed release
On 4 February 2011 16:09, Richard S. Hall he...@ungoverned.org wrote: So far, we are tied. :-) I guess that means you get the casting vote ;) - richard On 2/4/11 3:50, Guillaume Nodet wrote: Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version The vote will be opened for at least 72 hours. Happy voting! -- Cheers, Stuart
Re: [VOTE] Versioning after a failed release
Just to be clear does failed release mean: i) a release whose artifacts were published e.g. to apache.org/dist or maven central then found to be bad ii) a release that failed before the artifacts were published I had been working to ii) but I can see there could be confusion. Jeremy On 4 February 2011 08:50, Guillaume Nodet gno...@gmail.com wrote: Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version The vote will be opened for at least 72 hours. Happy voting! -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Versioning after a failed release
On 2/4/11 11:29, Jeremy Hughes wrote: Just to be clear does failed release mean: i) a release whose artifacts were published e.g. to apache.org/dist or maven central then found to be bad ii) a release that failed before the artifacts were published I had been working to ii) but I can see there could be confusion. Yes, (ii). This is when we call a vote, but then decide to cancel the vote for some reason. So the artifacts have never made it into maven central or apache.org/dist. - richard Jeremy On 4 February 2011 08:50, Guillaume Nodetgno...@gmail.com wrote: Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version The vote will be opened for at least 72 hours. Happy voting! -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Versioning after a failed release
On Friday, February 4, 2011, Jeremy Hughes hugh...@apache.org wrote: Just to be clear does failed release mean: i) a release whose artifacts were published e.g. to apache.org/dist or maven central then found to be bad Afaik, maven central has since a lng time a policy to never change a published artifact which definitely makes sense, so even if we want to do that (but which sane person would), it would not be possible. ii) a release that failed before the artifacts were published I had been working to ii) but I can see there could be confusion. Jeremy On 4 February 2011 08:50, Guillaume Nodet gno...@gmail.com wrote: Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version The vote will be opened for at least 72 hours. Happy voting! -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Versioning after a failed release
Well, I'm on the fence. On the one hand, I doubt that it helps much to skip the release number but granted, it might help for the bookkeeping in rather strange cases. On the other hand, it can suck a bit to not have a 1.0.0 version for example but at the same time, it's not super important either as I don't think we should worry about marketing versions much. Overall, I guess I'm slightly in favor of A but mostly because of the _can_ v.s. the _must_ of B. I think we should just let the release manager of the vote make that decision on a case by case basis (especially, as we clearly have no consensus on the topic). +1 for A (assuming its a _can_ and not a _must_) regards, Karl On Fri, Feb 4, 2011 at 5:17 PM, Richard S. Hall he...@ungoverned.org wrote: On 2/4/11 11:11, Stuart McCulloch wrote: On 4 February 2011 16:09, Richard S. Hallhe...@ungoverned.org wrote: So far, we are tied. :-) I guess that means you get the casting vote ;) No, no. I'm maintaining my 0. :-) Perhaps Karl has an opinion. - richard On 2/4/11 3:50, Guillaume Nodet wrote: Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version The vote will be opened for at least 72 hours. Happy voting! -- Karl Pauls karlpa...@gmail.com
Re: [VOTE] Versioning after a failed release
Assuming my vote counts, something I'm not sure about since I'm not a felix committer and I never could work out that part of the rules On 4 February 2011 17:17, Richard S. Hall he...@ungoverned.org wrote: On 2/4/11 12:10, Alasdair Nottingham wrote: In that case I change my non-binding B vote to a non-binding A vote. A (non-binding). The balance has tipped...A is now ahead by two! :-o - richard On 4 February 2011 16:37, Richard S. Hallhe...@ungoverned.org wrote: On 2/4/11 11:29, Jeremy Hughes wrote: Just to be clear does failed release mean: i) a release whose artifacts were published e.g. to apache.org/dist or maven central then found to be bad ii) a release that failed before the artifacts were published I had been working to ii) but I can see there could be confusion. Yes, (ii). This is when we call a vote, but then decide to cancel the vote for some reason. So the artifacts have never made it into maven central or apache.org/dist. - richard Jeremy On 4 February 2011 08:50, Guillaume Nodetgno...@gmail.com wrote: Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version The vote will be opened for at least 72 hours. Happy voting! -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Alasdair Nottingham n...@apache.org
Re: [VOTE] Versioning after a failed release
On 2/4/11 16:23, Alasdair Nottingham wrote: Assuming my vote counts, something I'm not sure about since I'm not a felix committer and I never could work out that part of the rules Technically, only PMC members vote count for legal purposes, but for something like this, I think we can use what ever definition of consensus we want. - richard On 4 February 2011 17:17, Richard S. Hallhe...@ungoverned.org wrote: On 2/4/11 12:10, Alasdair Nottingham wrote: In that case I change my non-binding B vote to a non-binding A vote. A (non-binding). The balance has tipped...A is now ahead by two! :-o - richard On 4 February 2011 16:37, Richard S. Hallhe...@ungoverned.orgwrote: On 2/4/11 11:29, Jeremy Hughes wrote: Just to be clear does failed release mean: i) a release whose artifacts were published e.g. to apache.org/dist or maven central then found to be bad ii) a release that failed before the artifacts were published I had been working to ii) but I can see there could be confusion. Yes, (ii). This is when we call a vote, but then decide to cancel the vote for some reason. So the artifacts have never made it into maven central or apache.org/dist. -richard Jeremy On 4 February 2011 08:50, Guillaume Nodetgno...@gmail.com wrote: Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version The vote will be opened for at least 72 hours. Happy voting! -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
