Am 14.04.2014 21:28, schrieb Joseph Rushton Wakeling:

On Wed, 02 Apr 2014 21:24:54 GMT, Sönke Ludwig wrote:

A beta version implementing the new version handling has been uploaded: http://code.dlang.org/download

Ha, I just installed the latest from-git dub and got bitten by this with my Dgraph library. That's what I get for not following up on dub ... :-)

Like a previous poster, I also use the "version": "~master" to indicate that I do not consider the library stable enough to support formal versioning yet.

That's what versions 0.x.y are supposed to be used for, according to
SemVer (or alternatively pre-release versions, such as 2.0.0-alpha.1).
Note that it can still be very useful to be able to depend on certain
milestones, even if everything is still unstable. Supporting specific
commit IDs would be a possible alternative, but there are additional
issues for branch based dependencies.

I'd therefore suggest that rather than deprecation-and-destruction, there be a warning which says something like: "Warning: this program builds directly from branch ~whatever. This may lead to breaking changes being brought in without prior notice."

I fear that this won't solve the issue that people are generally lazy
and thus don't create version tags, even when things get more stable
(most packages on code.dlang.org don't have versions). But you will
always be able to use a certain branch by using local overrides or by
editing the dub.selections.json file, if necessary, just not for the
basic dependency specifications.

I feel that this is a feature and not a flaw, and better way to deal with it may be to handle the way that code.dlang.org groups or promotes projects -- give explicitly versioned projects higher prominence, perhaps?

That was the original plan, which is why packages with versions are
placed first in the package list. But apart from this plan not working
out in practice so far, the final tipping point was realizing that the
idea of trying to make mixing branch and version based dependencies work
is fundamentally flawed. There is no universal recipe how to resolve two
different dependencies to the same package, once specified with a
version (range) and once with a branch. In practice, this will (did)
result in two clusters of libraries forming - those that depend on a
branch and those that depend on versions. This is a complete fail of the
package system, because it makes versions useless in many situations.

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.

Note also that local working copies are now handled as the latest
version tag that they are based off, instead of always handling them as
~branches. This results in DUB usually automatically picking the
matching working copy instead of downloading a version from the
registry, so that usually no local overrides or fiddling with
dub.selections.json is required in this case.