On 8/26/2014 7:39 AM, Sönke Ludwig wrote:

After a long pause, the next version of DUB is finally ready. It contains some major changes, of which especially one of them still requires some more careful testing to make sure that there are no regressions.

As you may have already heard or noticed, specifying dependencies with a ~branch used for the version specification has been deprecated, as it became obvious that supporting this is impractical for the overall ecosystem. Please have a look at the wiki for more information about this topic.

I recognize the very real problem this latest dub is trying to solve,
and I have to admit I agree to the extent that perhaps "~master"
dependencies should be banned or at the very least not be made so easy &
tempting.

But I find the general approach troubling.

I love that we have dub, and I genuinely want to get more use out of
it. But as I've partially mentioned in another thread (that time I was
talking within the context of project building), my one big roadblock
problem with dub is it tends to be fairly "my way or the highway". If
your project wants to use dub (either for dependency management,
publishing or building), then it frequently feels like dub demands your
project to be designed and managed "the dub way", all or nothing.
Consequently I'm unable to rely on dub as much as I'd like.

Some things have gotten a lot better. For example, the old
requirements that the sources be in a directory named "source" and that
the "main()"-containing file be named "app.d" are mercifully long gone.
But I still keep getting the feeling that dub hasn't quite shaken the
general "the dub way or get out" approach to things.

I'm more than willing to get into actual specifics and submit pulls, of
course.

As for my thoughts on this specific matter at hand, the subject of
branch dependency deprecation:

  • Master Branch Dependency:

I'm fine with eliminating broad branch dependencies on the master
branch. Although, if it doesn't already exist (I think it may?) I'd like
to see a way for a user to get around that for their own project (just
not for projects within the dub's public repo). This can, and perhaps
should, be somewhat of a bother to do, but it should at least be
possible if it isn't already. Manual overrides are important.

  • General Branch Dependency:

I feel like eliminating all branch dependencies (ie, not just on
master) may be overkill. I haven't actually checked, but I'm guessing
the vast majority of the problems we have are specifically on "master"
branches. Has there really been much issue with non-master branches so far?

Eliminating these seems like throwing the baby out with the bathwater: I
think it'd be entirely reasonable for a project (and this fits within
the spirit of semantic versioning) to create and maintain
no-breaking-change branches. For example, v1.3.1, v1.3.4 and v1.3.27
could all be tags on a stable "v1.3.x" branch. That may have various
pros/cons, but I don't think it's appropriate for dub to categorically
eliminate things like this unless there actually IS a real and
significant problem that can only be solved that way. I'm not sure
that's actually the case here, my understanding is that only "master"
has been a real issue.

  • Tag Names:

Speaking of versioning, I like semantic versioning. A lot. I'm all
for it. But...dub has no business mandating it or otherwise getting in
the way of projects/tags that, for whatever reason, don't use it. Not
allowing dependencies on arbitrary tag names (for example:
"johnnys-super-release" or "stupid-code-name-like-horny-hippo") is just
plain straight-jacketing. (At least, I think that's still a limitation
of dub, or has it been lifted?) Dub's add-local/path/override, while
nice features, are not sufficient for this. Depending on a specific tag
is a simple thing, it should be simple to do. Tossing it in the
"version" field should "just work".

  • Commit Hashes:

Much the same as tag names. This is an occasionally-necessary escape
hatch. Especially if the "~master" dependency is eliminated. Sometimes
you need a specific commit for whatever weird reason, and requiring
cooperation from the given project's maintainer is both insufficient and
unnecessary. Dub's add-local/path/override is also an insufficient
solution here, as is this new "dub.selections.json" thing that I don't
even understand yet. This is a simple thing, I should be able to expect
tossing a commit hash (or arbitrary tag name) into the "version" field
of a dependency to "just work".

  • Official Repo:

One thing I do think would be a good idea, if it isn't already in
place (maybe it already is?), is if dub's official repo required newly
submitted repos to already contain at least one tag before the new
project actually becomes "active" in the repo and can start being used.