Please use consistent version number

[tillea]

Hi,
as you can read in a Debian bug report the version tuple encoded in the library and in the pkg-config metadata does not match. While there is a patch attached for Debian I think it makes more sense if you solve this in your upstream code since you are planing a new release anyway.
Kind regards, Andreas.

[ntamas]

Not sure what's wrong there -- I took a look at the official tarball of 0.8.1 and igraph.pc as well as IGRAPH_VERSION includes the correct version number (i.e. 0.8.1). Is there something else going on in the Debian build process?

[tillea]

On Tue, Apr 28, 2020 at 04:24:07AM -0700, Tamás Nepusz wrote: Not sure what's wrong there -- I took a look at the official tarball of 0.8.1 and `igraph.pc` as well as `IGRAPH_VERSION` includes the correct version number (i.e. 0.8.1). Is there something else going on in the Debian build process?

I remember when I did the testsuite issue related builds I stumbled upon strings saying 0.9.0-pre or something like this. The Debian build does not randomly bump version strings, thought. I've found $ cat tools/NEXT_VERSION 0.9.0 No idea where this is used.

[ntamas]

That file should only be present in the development version if you do a checkout from the develop branch. The idea is that tools/getversion.sh generates a version number like ${NEXT_VERSION}-pre+${commithash} if you are compiling things from the development branch, but it uses ${CURRENT_VERSION}-post+${commithash} if you are compiling things from the master branch -- unless you are standing on a tagged revision, in which case it uses the exact tag of that revision.

[tillea]

OK, than you should not include that file into the tagged download tarball: wget http://github.com/igraph/igraph/archive/0.8.1.tar.gz $ tar taf igraph-0.8.1.tar.gz | grep NEXT_VERSION igraph-0.8.1/tools/NEXT_VERSION The file is definitely inside the tagged download which Debian is using. Its surely possible to exclude that file explicitly to be safe. Kind regards, Andreas.

[ntamas]

Hmmm, that's not the released tarball, that's the snapshot of the Git repo corresopnding to the revision tagged by 0.8.1. The official tarball is this one:

https://github.com/igraph/igraph/releases/download/0.8.1/igraph-0.8.1.tar.gz

The source of confusion is probably the fact that if you navigate to the release page on Github, it shows "Source code (tar.gz)" at the bottom of the release box when it is actually referring to the snapshot of the Git repo. The released tarball is attached to the release separately.

[ntamas]

Nevertheless, I'll try to patch the build process so it does not use NEXT_VERSION if you use the snapshot from Github. It should use NEXT_VERSION only if the file is actually part of a Git repository (which is not true if you simply extract the tarball).

[tillea]

On Tue, Apr 28, 2020 at 05:46:24AM -0700, Tamás Nepusz wrote: Hmmm, that's not the released tarball, that's the snapshot of the Git repo corresopnding to the revision tagged by 0.8.1. The official tarball is this one: https://github.com/igraph/igraph/releases/download/0.8.1/igraph-0.8.1.tar.gz

Uhhhh, how can this automatically detected. In Debian there is tool uscan which parses a website for a regexp string to detect new versions. For all github projects I know it is save to parse https://github.com/igraph/igraph/releases If you have some alternative page linking to what you call "official tarball" I could point uscan to that place.

The source of confusion is probably the fact that if you navigate to the release page on Github, it shows "Source code (tar.gz)" at the bottom of the release box when it is actually referring to the snapshot of the Git repo. The _released_ tarball is attached to the release separately.

Yes. It works for all projects I know except igraph. If you ask me also for other consumers than Debian I'd care for making the tarball in .../releases identical to your "official tarball". It could confuse other users as well! Kind regards, Andreas.

[tillea]

On Tue, Apr 28, 2020 at 05:48:07AM -0700, Tamás Nepusz wrote: Nevertheless, I'll try to patch the build process so it does not use `NEXT_VERSION` if you use the snapshot from Github. It should use `NEXT_VERSION` only if the file is actually part of a Git repository (which is not true if you simply extract the tarball).

That would be helpful, Andreas.

[szhorvat]

Uhhhh, how can this automatically detected.

I just checked what MacPorts does and it seems to be able to use the release tarball. One can choose to get the source from "release" (which is this) or from "archive" (which Debian uses).

https://guide.macports.org/#reference.portgroup.github.distfilestrategy

One can use the GitHub releases API to get the release, but I think MacPorts simply makes assumptions about the name of the tarball based on the information provided in the portfile (and a way to override these assumptions if they are incorrect).

The link is:

https://github.com/igraph/igraph/releases/download/0.8.1/igraph-0.8.1.tar.gz

I think this is computed roughly as

https://github.com/${user}/${name}/releases/download/{$version}/${name}-${version}.tar.gz

where user, name and version are provided in the portfile.

I don't know how Debian handles these—can a similar approach be used without too much trouble? The fact that MacPorts has an explicit way to use GitHub releases suggests to me that many other projects may release the source in a similar way.

EDIT: Basically the only thing one needs to change when moving to a new version is the version.

[ntamas]

If you have some alternative page linking to what you call "official tarball" I could point uscan to that place.

https://igraph.org/c/#downloads contains a link that links to the correct Github URL.

If you ask me also for other consumers than Debian I'd care for making the tarball in .../releases identical to your "official tarball".

The Git repo contains lots of stuff that is not necessary for building igraph from source. Nevertheless, it does not hurt to have these in the Github archive and it won't disturb the build process, apart from the presence of the tools/NEXT_VERSION file.

I have now committed a change to tools/getversion.sh such that it simply extracts the version number from the changelog if it is not within a Git repo. Furthermore, the Github archive for version 0.8.2 and later will not include tools/NEXT_VERSION because this file is now present on the development branch only. Hopefully this will be enough.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.