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 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
openSUSE's guideline 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.
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".
% git tag -m '' v1.8.5-rc1
GIT_VERSION = 1.8.5-rc1-dirty
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