On Sun, Jun 2, 2013 at 8:44 PM, Fred Cooke <[email protected]> wrote: > Although I prefer to use Git, it's totally irrelevant. I'm unsure how you > came to the conclusion that I thought this was anything to do with Git. > Subversion tags, though mutable, should not EVER be committed against or in > any other way modified.
Doing so is the behaviour of a (bad quality) grad > student, not a software development professional! Fred, Do you realize that those are, ahem, 'fighting words'? That this development community, along with a slew of other Apache communities, have treated this as a good practice for years? The net effect is that you calling us all unprofessional idiots. We may eventually change over to your preferred methodology, but insulting us wholesale is not, in my opinion, a very effective way to move opinion in your direction. Our policy has been that we want the SVN/scm tag to be one-to-one with the voted source which is one-to-one with the Maven metadata. Deleting and creating tags is consistent with that policy so long as we don't modify them thereafter. And we don't. --benson > > On Mon, Jun 3, 2013 at 2:31 AM, Chris Graham <[email protected]> wrote: > >> Fred, >> >> We are talking more process here. Not the specifics of an individual SCM, >> not everything is in git. We are still talking about the abstraction api >> that the maven-scm handlers provide, of which git is but one. >> >> -Chris >> >> >> On Mon, Jun 3, 2013 at 4:42 AM, Fred Cooke <[email protected]> wrote: >> >> > > from my experience, even if this question is not absolutely >> scm-specific, >> > > git >> > > brings us a new problem we didn't have with svn: once a tag is set on >> the >> > > canonical repo and replicated on developers' repos, it is not >> > automatically >> > > updated if updated in the canonical >> > > >> > >> > Git brings you no such "problem", it simply exposes your extremely poor >> > practices... A tag should, and in any sane place is, permanent and >> > irrevocable. >> > >> > On another note, the veto by -1 vote mechanism is a great idea for a >> > release, but a terrible idea for a principle like this. For a release it >> > requires a justification, for this it's just "my opinion" overriding one >> of >> > Maven's core principals. >> > >> > Stagnation wins. >> > >> > Fred. >> > >> > >> > > >> > > but I may miss some git-fu once again... >> > > >> > > Regards, >> > > >> > > Hervé >> > > >> > > Le samedi 1 juin 2013 20:47:36 Chris Graham a écrit : >> > > > >but as I see, there seems to be a consensus around a 2-sided rule: >> > > > >- don't reuse version number for pre-releases (RC, etc) >> > > > >- reuse version number for actual releases >> > > > >> > > > Not sure how I feel about that. >> > > > >> > > > alpha/beta/RCx etc, they are all still valid version nos, so I think >> > that >> > > > the no re-spin rule should still apply in the same manner. >> > > > >> > > > -Chris >> > > > >> > > > On Sat, Jun 1, 2013 at 8:41 PM, Hervé BOUTEMY <[email protected] >> > >> > > wrote: >> > > > > yes, the vote for one unique rule is clearly "-1" >> > > > > >> > > > > but as I see, there seems to be a consensus around a 2-sided rule: >> > > > > - don't reuse version number for pre-releases (RC, etc) >> > > > > - reuse version number for actual releases >> > > > > >> > > > > Regards, >> > > > > >> > > > > Hervé >> > > > > >> > > > > Le samedi 1 juin 2013 08:27:38 Stephen Connolly a écrit : >> > > > > > I will need to recheck the tally, but I think the result is -3 >> > > > > > >> > > > > > So looks like we will be reusing version numbers on respins >> > > > > > >> > > > > > On Wednesday, 29 May 2013, Stephen Connolly 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 >> > > >> > > --------------------------------------------------------------------- >> > > To unsubscribe, e-mail: [email protected] >> > > For additional commands, e-mail: [email protected] >> > > >> > > >> > >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
