RejectedSoftware Forums

Sign up

Pages: 1 2

Re: Application version numbers

On 02.02.18 14:16, Jacob Carlborg wrote:

On Fri, 2 Feb 2018 11:49:08 +0100, Christian Köstlin wrote:

Does this also work for you when you add versions to libraries?
Is $PACKAGE_DIR always set to the package, that is just build?
e.g. an executable has a dependency to a libarary with a version.

Check the three variables at the top of the "Environment variables" section [1]. $<name>_PACKAGE_DIR should work.

[1] http://code.dlang.org/package-format?lang=sdl#environment-variables

Thanks for mentioning this.
I looked into it, and it looks like, dub is setting
ROOTDUBPACKAGEDIR (for the main project you are actually building)
and DUB
PACKAGE_DIR for packages that are dependencies and build in the
process.

i changed my tool to first try to resolve the version from the dub.json
(that is part of every package in ~/.dub/packages), then from dub.sdl
then from git.

thanks again,
christian

Re: Application version numbers

CMake, SCons, Meson, etc. are not bound to build in a Git (or any other VCS) repository, in fact they focus on building a source tree. That package building for the Dub repo works with Git repositories and tags is the problem.

Re: Application version numbers

On 05.02.18 14:39, Russel Winder wrote:

CMake, SCons, Meson, etc. are not bound to build in a Git (or any other VCS) repository, in fact they focus on building a source tree. That package building for the Dub repo works with Git repositories and tags is the problem.

Funnily it looks like the git information is missing from the packages
stored in ~/.dub/packages ... also its not a 1:1 match to the git repos.
e.g. i have only dub.sdl files in my repos, but if i dub the packages
there is a transformed dub.json file.

christian

Re: Application version numbers

Clearly the Dub workflow is all about using Git. However other workflows builds from a release tarball so there is no use of git commands in such a situation. So for example, Debian packaging happens from release tarballs.

Whilst it might be an irritant, until everyone always uses Git for everything, relying only on git tags on a repository isn't going to work for build workflows other than creating Dub packages.

Re: Application version numbers

On 2018-02-05 19:47, Russel Winder wrote:

Clearly the Dub workflow is all about using Git. However other workflows builds from a release tarball so there is no use of git commands in such a situation. So for example, Debian packaging happens from release tarballs.

I actually think it's kind of annoying that Dub ties a Git tag to a new
version of the Dub package. I might not want to release a new Dub
package for every Git tag. At the same time "git describe" is very useful.

The simplest thing to do is probably to have the version specified in a
separate file that included with the "import" expression. One would
build a small tool/script to also create a Git tag by reading this file.

/Jacob Carlborg

Re: Application version numbers

Having a file VERSION is definitely my preferred option and then a tag in the Git repository as well. Yes there are two places the version is specified, but I think this is the least worst way of working.

Re: Application version numbers

I played a little bit more around with a small program, that creates a
packageversion-module for me.
e.g.

module colored.packageversion;
const PACKAGE_VERSION = "v0.0.10-dirty";
static this()
{
    import packageversion;
    packageversion.registerPackageVersion("colored", "v0.0.10-dirty");
}

What really comes in handy (imho) is if every dub package would provide
such a thing. Then you could print an exact version of your code, as
well as of the code of all dub-dependencies.

e.g.
import asciitable;
import packageversion;
auto table =
packageversion

.getPackages
.keys
.sort
.fold!((table, key) =>
  table.add(key, packageversion.getPackages[key]))

(AsciiTable(0, 0));
"Versions:\n%s".format(table.toString(" ", " ")).writeln;

could produce something like this:
Versions:

androidlogger v0.0.6
asciitable    v0.0.2-4-gb6a99a6
colored       v0.0.10-dirty
worker        v0.0.2-11-g09440eb-dirty

what do you think?

christian koestlin

Pages: 1 2