RejectedSoftware Forums

On Mon, 14 Apr 2014 20:32:50 GMT, Joseph Rushton Wakeling wrote:

On Mon, 14 Apr 2014 22:10:02 +0200, Sönke Ludwig wrote:

At this point I'm convinced that always using versions is the way to go.
Just tagging a new v0.0.x or something similar after a couple of days or
after each feature/important bug fix is trivial and helps a lot to at
least let any dependent libraries be stable as long as they target a
specific version.

Just to make sure I understand, how is this meant to work in terms of what's in package.json, what is tagged on the master branch (do there need to be git tags?), and what should be done with the version indicators in package.json in the development branch in-between version releases?

Regarding the tags, yes there always need to be version tags. It doesn't matter on which branch(es) they are on, though. For example the libgit2 binding only has source code in secondary branches.

For development branches, you'd usually use a pre-release version, such as 2.0.0-dev.1, 2.0.0-pre.1, 2.0.0-alpha.1 or similar. For the initial development, all the 0.x.y versions can be freely used without having to regard the usual backwards compatibility requirements.

I usually kind of like the even-odd version scheme, where even minor numbers mean stable versions and odd numbers mean development, but unfortunately SemVer forbids this kind of use (and, to be frank, makes versions a lot more useful by doing that).

On Wed, 07 May 2014 13:28:41 GMT, Mike Parker wrote:

On Wed, 07 May 2014 07:21:48 GMT, Sönke Ludwig wrote:

Exactly, tags are picked up regardless of the branch they are on. And as long as each branch uses a unique major (or minor) version, the natural version selector ~> will make sure that people will automatically stay on that branch.

Thanks for the help so far. Just to make sure I understand this... When you say ~> will keep people on a specific branch, you mean through restricting the dependency to the range of tags that only exist on that branch? I want to make sure I completely understand this.

Given branches v2.0.0, v2.0.1 and v2.0.2 (the current scheme), I now plan to add tags as follows:

v2.0.0 branch - v1.0.x tags.
v2.0.1 branch - v1.1.x tags.
v2.0.2 branch - v1.2.x tags.

1) With this setup, assuming someone wants to work exclusively with the 2.0.1 branch, what should the dependency look like? If I correctly grok what you say above, it should be ~>1.1.0, correct?

2) Later on, if I add a new branch v2.1.0 with tags v2.0.x, can I assume there will be no conflict between the 2.0.x tags and the 2.0.x branches?

Once I get these last two points cleared up, I'll be ready to implement this. Assuming, of course, that it doesn't require an unreleased version of dub (with deprecated branches).

Yes, that sounds all right. ~>x.y.z is just a short hand for >=x.y.z <x.y+1.0, so it will exclude any versions with a different minor version. Similarly, ~>x.y is a shorthand for >=x.y.0 <x+1.0.0, so it would force the same major version.

BTW, I'd recommend to name the tags v1.1.x+sdl.2.0.1 and so on, so that it becomes immediately clear which SDL version is required. Oh and no new DUB version is required, the new version is supposed to just add the warning message and handles package resolution a bit different, but the version matching stays the same.

I have a separate concern with tags when using sub-packages heavily.

As you know, sub-packages might currently reference each other by ~branch (and ~master is appropriate for this for reasons we will see below).

If I understand correctly, I will need to transition to version tags on next dub release, for good reasons. Sub-package sharing the same repositery will mean: fixing subpackage A:subA implies releasing a new subpackage A:subB even if not changed, but this is my problem as I choose to use the same repositery.

My concern is that when I make a new release, I will need to update the dub.json package each time, so that sub-packages references refers to the good (non existing yet!) version version tag. To that end, ~master was good since it also means "same version than me".

I need a macro (eg: "=self" instead of ">=x.y.z") to mean than the dependency should use the same version as the dependent package. That will keep sub-packages as practical as they are now.

Eventually the syntax might be ">={self|number}.{self|number}.{self|number}" so that sub-package versionning stays possible and flexible.

Many fixes related to the new dependency version resolution algorithm have been incorporated in this new beta release. There are no release blocking known issues left, so please test thoroughly and file a bug report for every error/misbehavior that occurs in 0.9.22-beta.3, but didn't in 0.9.21, so that we get a solid release.

Precompiled binaries, as always, can be downloaded at http://code.dlang.org/download (Latest preview)