On Tue, 2009-10-20 at 20:31 -0700, David Brownell wrote: > On Tuesday 20 October 2009, Zach Welch wrote: > > > > > > If we go this route, would we even need to expose an '-old' GIT tree? > > > > > > In one word: backup! > > > > I was careful in the use of the word "expose". :) Yes, we definitely > > want to create a copy on the server for backup purposes, but does it > > need to be published for distribution? > > The way things are set up, I'm not sure where to store it > that would *NOT* be publicly visible ... is that a big deal? > It's going to be a temporary thing in any case.
Fair enough. I just want to minimize vestigial artifacts. :) > Different issue ... the "0.2.0" tag has already been made, > so after re-basing, we can't really change what that means. >From the discussion on this page about "retagging", http://www.kernel.org/pub/software/scm/git/docs/git-tag.html > How about ... just calling it "0.2" (and then "0.3" etc)? ... this would be option #1. Arguably, the sane thing to do. :) Since the $SUBJECT shows that we remain "in transition" between SVN and GIT, we could probably take option #2 too. It even provides a template for the e-mail that details the actions users can take to remove the old 0.2.0 tag. We're more-or-less at a flag day anyway, right? > If we ever need put out a bugfix we can go from Major.Minor > to Major.Minor.DOT easily enough, but meanwhile that extra > zero seems to add no real value. I see the .0 much like a $.99 price tag. The least-significant digits have subtle psychological influence on consumers. I think they help denote the amount of change since the last version more clearly. Also, the three-digit standard is easier to handle in the release scripts, so your suggestion adds more logic for me to get wrong. ;) What about "openocd-x.y.z"? With GIT, that allows cleanly distinct tag clouds in forked copies (e.g. "freeocd-*", "gnuocd-*", etc.). :) While we could use 'x.y.z' ourselves, the two forms of tags again make automation slightly more challenging.... Too forward thinking? Cheers, Zach _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
