On Fri, Sep 13, 2013 at 1:16 PM, Junio C Hamano <gits...@pobox.com> wrote: > Felipe Contreras <felipe.contre...@gmail.com> writes: > >> If the version is 'v1.8.4-rc1' that is the version, and there's no need >> to change it to anything else, like 'v1.8.4.rc1'. >> >> If RedHat, or somebody else, needs a specific version, they can use the >> 'version' file, like everybody else. >> >> Signed-off-by: Felipe Contreras <felipe.contre...@gmail.com> >> --- > > I already explained to you why this is a bad change.
No, you did not. All you did is throw a non sequitur argument which I already exposed as such. > When we say "we try to avoid regressions", we really mean it. Maybe by "regressions" you mean progress. > Before coming up with a change to pay Paul by robbing Peter, we must > make an honest effort to see if there is a way to pay Paul without > robbing anybody. There is, because Peter, the RedHat maintainer, can do exactly the same that Alice does; use the 'version' file. In fact, Peter, cannot possibly use Git's version because of this: % rpmdev-vercmp git-1.8.4 git-1.8.4.rc1 git-1.8.4 < git-1.8.4.rc1 % rpmdev-vercmp git-1.8.4 git-1.8.4-rc1 git-1.8.4 < git-1.8.4-rc1 % rpmdev-vercmp git-1.8.4 git-1.8.4~rc1 git-1.8.4 > git-1.8.4~rc1 Fedora's guideline[1] is to use a format like git-1.8.4-1.rc1, then the final release would be git-1.8.4-2, in other words, the '.rc1' is mostly informative, but that has nothing to do with Git's internal version (git-1.8.4.rc1). openSUSE's guideline[1] prefers to use git-1.8.4~rc1. Either way, none of them could possibly use git-1.8.4.rc1, because that's greater than git-1.8.4. > This change forces existing users who depend on how dashes are > mangled into dots to change their tooling. No, it does not. You just say that, and you assume because you said it, it must be true; it's not. First of all, nor RedHat, nor any other RPM-based distribution needs this any more, because as a simple search demonstrates, they don't use release candidates any more. http://www.rpmfind.net/linux/rpm2html/search.php?query=git&submit=Search+... Essentially, Peter is a figment of your imagination. The closest thing to Peter 1) doesn't use release candidates, and 2) if he did, he wouldn't use a version like git-1.8.4.rc1. > We do occasionally make deliberate regressions that force existing > users to change the way they work, but only when there is no other > way, and when the benefit of the change far outweighs the cost of > such an adjustment, and with careful planning to ease the pain of > transition. The updates to "git add" and "git push" planned for 2.0 > fall into that category. > > There has to be a benefit that far outweighs the inconvenience this > patch imposes on existing users, but I do not see there is any. "If > somebody needs a specific version, they can use the 'version' file" > does not justify it at all; it equally applies to those who want to > use a version name with a dash. > > Besides, the patch does not even do what it claims to do; if the > version is "v1.8.4-rc1", what you get out of the updated code is > "1.8.4-rc1", still losing the leading "v". Wrong. % git tag -m '' v1.8.5-rc1 % ./GIT-VERSION-GEN GIT_VERSION = 1.8.5-rc1-dirty [1] https://fedoraproject.org/wiki/Packaging:NamingGuidelines#NonNumericRelease [2] http://en.opensuse.org/openSUSE:Package_naming_guidelines -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
