Re: [PATCH v4 2/2] version-gen: fix versions

On Mon, Oct 14, 2013 at 12:01 AM, Jonathan Nieder [off-list ref] wrote:

Hi,

David Aguilar wrote:

quoted

Felipe Contreras [off-list ref] wrote:

quoted

quoted

Virtually all packaging guidelines would prefer 1.8.4~rc1, over
1.8.4.rc1 or 1.8.4-rc1, so it makes sense to use that instead.

In particular, the only packaging we provide, git.spec, generates a
wrong version, because git-1.8.4 < git-1.8.4.rc1, changing to ~rc1 fixes
the problem as it's considered newer.

A more conservative fix would be to tweak the .spec generation in the
Makefile to follow whatever the appropriate Red Hat convention is.
For example, something like this:

It's not Red Hat's convention, it's RPM, and dpkg, so basically every
package manager that most distributions out there use.

And I already sent a patch for that which was ignored:

http://article.gmane.org/gmane.comp.version-control.git/234794

That wouldn't work; VERSION doesn't have '-rc', it has '.rc'. and
what's the point of creating a new variable? It's a was of space.

 git.spec: git.spec.in GIT-VERSION-FILE
-       sed -e 's/@@VERSION@@/$(GIT_VERSION)/g' < $< > $@+
+       sed -e 's/@@VERSION@@/$(GIT_VERSION_RPM)/g' < $< > $@+
        mv $@+ $@

 GIT_TARNAME = git-$(GIT_VERSION)
-- 8< --

That way, programs that parse the git version by splitting at '.'
(there are more than a few, unfortunately) would continue to work,

Do you have any evidence that such programs exist? Specifically,
programs that work with 1.8.4.rc1, but not 1.8.4-rc1 or 1.8.4~rc1. I
find that very very very unlikely.

Anyway, in the very very very unlikely scenario that somebody's script
does break they can report that, and we can revert. What's the
problem?

but
the packaging system would get the benefit of the proposed versioning
style change.

quoted

quoted

The same happens in dpkg.

Have you tested this?

% dpkg --compare-versions 1.8.4 gt 1.8.4~rc1 && echo yes || echo no
yes
 % dpkg --compare-versions 1.8.4 gt 1.8.4-rc1 && echo yes || echo no
no

I thought the Debian packaging did not use the
GIT-VERSION-GEN generated version in this way.

It doesn't matter. The name of the package would be git-1.8.4~rc1, and
'git --version' would return 1.8.4.rc1, that's inconsistent.

Why be inconsistent when we can be consistent?

[...]

quoted

This seems related:

http://lintian.debian.org/tags/rc-version-greater-than-expected-version.html

If I understand correctly, that page has an exhaustive list of affected
packages in the Debian archive and doesn't include git.

Because a) they don't package release candidates, and b) they use a
different version (s/\./~/).

-- 
Felipe Contreras