On Mon, Jun 3, 2013 at 10:52 AM, Benson Margulies <[email protected]>wrote:
> 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, Nicely worded. And thanks for pointing out the " so long as we don't modify them thereafter. And we don't." bit. That is the well understood process, one that I think is valuable (as we all understand [and adhered too]). -Chris --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] > >
