On 2013-09-15 12:43, Sönke Ludwig wrote:

Finally got NNTP working :)

Since the default build type is "debug" that should definitely be included. Executing the equivalent of "dub build" and "dub build --build=release" for each newly installed package would basically do this. Once a better build system is in place that would be an option.

As far as I know, the only thing the -debug flag does is enable the
"debug" statements. Most of the use cases I have seen prints some
information to the console. I would really hate to have that by default.
That's only useful when one needs to debug a third party package which
doesn't behave as it's supposed to. I think that by default we should
assume that they do behave as they're supposed to.

What is useful is to have debug symbols, that is the -g or -gc flag.

Difficult call with the branches and starting tracking just after the first version tag. It would be a lot cleaner, but on the other hand there are a lot of packages now where the author doesn't feel comfortable yet to start tagging versions (even if that is an unjustified feeling). IF we end up with half the number of packages by forcing version tags, that would arguably be worse overall for the system.

Hmm.. maybe a little psychological trick can help here: non-tagged packages could always occur after tagged packages in the list (assuming that they are in a pre-release state) or get some kind of visual "beta" tag, so that the author is kindly forced to start making tagged versions to get more people to use their packages.

A "beta" flag or similar might be a good idea. Possibly a button to
show/hide these beta packages. The idea of sorting non-tagged package
last is also good.

We should come up with a better name than "beta" since according to the
semantic versioning scheme you're allowed to have versions like
"0.2.0-beta", "0.2.0-alpha" and "0.2.0-rc1".

True, but I also often have the situation with vibe.d that a quick fix is needed for someone and making a release would be too much effort. But maybe in that situation I should start thinking more about pre-release versions (e.g. "0.7.18-pre.1"). I'm not even sure if and how these are currently matched by DUB when using ">=0.7.17".

You don't want a pre-release tag for every new commit :)

Comparing with Bundler again. In this case one would be forced to
specify the fully git repository.

Standard bundler:

git "rails", "4.0.0"

Track git HEAD:

git "rails", github: "rails/rails"

Or when it's not on github:

git "rails", git: "git@github.com:rails/rails.git"

http://bundler.io/v1.3/git.html

/Jacob Carlborg