RejectedSoftware Forums

Am 14.02.2014 20:46, schrieb Jacob Carlborg:

On 2014-02-13 21:38, Sönke Ludwig wrote:

I mean a path to a cloned working copy, not a local "git remote".

Git can clone from a cloned working copy as well.

I know, what I meant was the role it plays - being used as a local
directory to work on or as a source for a git clone/push/pull command.

That would avoid the burden for DUB to perform the clone/checkout

Dub could of course check if it's a local path.

, possibly managing credentials etc. and provide full flexibility for
the user.

Right.

DUB wouldn't even have to know what branch/tag is checked out and any VCS
would work.

Right. I'm not against supporting a local path but I think supporting
arbitrary git repositories would be nice as well. Bundler (a tool used
by Ruby projects) supports gems (which would correspond to a package in
the dub registry), git repositories and local file paths. It also
supports "shortcuts" for github repositories. When using a git
repository it will by default used the default branch.

Ah okay, I didn't think of combining the version pinning with this. My
only concern is when you want to check in the pinned versions, but have
different requirements for developers on the team vs. external users.
But I guess you just wouldn't commit the development pinning in that case.

My idea was originally to separate the two, but of course they would
still interfere with each other and it may actually not be the ideal
approach.

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

The idea is that it should work for the same dependency graphs as before, but issue warnings whenever branch based dependencies are encountered. However, there have been some deep changes that probably still broke some stuff. Also, performance is sometimes lacking and the error message for unresolvable dependency graphs is bad. But I think everything is now complete enough to start looking for regressions and to start stabilizing everything.

In addition to that, I've started to change the dependencies of the my own packages to reference tagged versions, so that may also require some updates to resolve conflicts.

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.

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.

I disagree. Consider DerelictSDL2. My plan for it (and most of the Derelict packages) is for release versions to mimic the version of SDL which the binding was created against. That's the only sensible way for me to handle it. The reasoning is that newer versions of SDL sometimes add new functions. Once I update the binding, then that version of the binding can no longer load older versions of the SDL library. Now, the latest release is SDL 2.0.3. Let's assume that someone finds a bug in the 2.0.1 binding. If I were using tags, there would be no way for anyone using the 2.0.1 binding to get the update without getting all of the new stuff from the later versions as well, meaning they would also have to change their app's dependency to the latest version of SDL2 when there's really no need to do that. By using branches, I can ensure that Derelict users can require the minimum version of SDL2 they want for their apps and not force them to use the latest version.

In other words, if support for branch-based dependencies is dropped, the entire structure of DerelictOrg is broken and I'm back to the bad old days of breaking people's apps every time they update Derelict. I moved to a dub-based, multi-repository framework in order to fix that :)

On Fri, 02 May 2014 10:08:38 GMT, Sönke Ludwig wrote:

If proper SemVer versions are used, there is no problem. This will mean that there is not necessarily a one-to-one correspondence between the original version digits and those of the binding, but it will naturally support bugfix releases for the original library, as well as for the binding. The "build metadata" part of the version can be used to denote the exact SDL version the binding is based on (will be ignored when comparing versions). Example:

SDL 2.0.1            => DerelictSDL 1.0.0+sdl-2.0.1
SDL 2.0.1 + bugfix 1 => DerelictSDL 1.0.1+sdl-2.0.1
SDL 2.0.1 + bugfix 2 => DerelictSDL 1.0.2+sdl-2.0.1
SDL 2.0.2            => DerelictSDL 1.0.3+sdl-2.0.2 (assuming SDL 2.0.2 contains only bugfixes and is fully API/ABI compatible)
SDL 2.0.3            => DerelictSDL 1.1.0+sdl-2.0.3 (assuming SDL 2.0.3 contains only backwards compatible changes)
SDL 2.1.0            => DerelictSDL 2.0.0+sdl-2.1.0 (breaking changes, could be maintained in parallel on a separate "2.1.x" branch)

Instead of choosing a branch, the user of the library then uses "derelict-sdl": "~>1.0.0" or "derelict-sdl": "~>1.0" to get only bug fix or backwards compatible releases. The good thing then is also that people can do "derelict-sdl": "1.0.2" or "derelict-sdl": ">=1.0.0 <=1.0.2", should there be any unintended breaking changes in 1.0.3.

My problem is that SDL 2.0.1 adds new functions and 2.0.2 adds new functions. Derelict loads functions dynamically, so if anyone is using a version of Derelict implemented against 2.0.2, then they will get exceptions when trying to load earlier versions of SDL. That means that if I tag Derelict bug fixes on the same branch, anyone requiring older versions of SDL will not be able to take advantage of it (unless they use Derelict's selective loading mechanism, but that can really get out of hand and was not intended for this sort of thing).

But this bit "breaking changes, could be maintained in parallel on a separate '2.1.x' branch" has me curious. Are you saying that dub can pick up tags across multiple branches? Given the existing 2.0.0 and 2.0.1 branches, let's say I start tagging the former with 1.x.x and the latter with 2.x.x. Will dub pick up all the 1.x and 2.x tags?