Am 15.09.2013 13:20, schrieb Jacob Carlborg:
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.
In this case "debug" means both, -debug and -g/-gc, but I agree that -g
is the important one.
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".
Maybe just "unversioned" and slightly grayed out or similar?
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
Okay but that's not that much different from using "~master". I think
the most important achievement is to minimize the number of packages
without version tags. At least I'd assume that people would
automatically stay with version based dependencies if possible when all
they see in the registry has versions.