On 2013-09-11 18:11, Sönke Ludwig wrote:
It will only look at version tags of the form vA.B.C(postfix) any reason
to hide one of those? It could be added as a feature to the registry,
but is there a compelling use case to warrant the costs?
No, that should be ok.
"or", you can choose which using "dub --config=library" or "dub
--config=application" (the default).
Ok, I see. I got confused by the documentation:
"Automatically detects the target type. This is the default global value
and causes dub to try and generate "application" and "library"
configurations"
It says '"application" and "library"'. I think you should update to say
"or" to avoid this confusion.
Works for me, but master was broken for some hours. Maybe you caught a
bad version?
No, I don't think so, I was using 0.9.17. What's the expected
output/file(s)?
I just don't know if that can be generalized to everyone or at least the
majority of users. Maybe this is a good topic for starting a wider
discussion/poll.
When you start using enough packages it will cause problems.
If used correctly, by definition, it _does_ help. Reality, especially in
the fast moving D environment, may be different, though. However it
seems to work quite well in the C world.
It helps, but it won't fix or make the problem go away.
By upgrading and getting updates of indirect dependencies, even if the
main package wasn't updated.
Then you get specify that instead in the dependency list. Most often I
don't care about indirect dependencies, as long as everything works. If
I get a new version of an indirect dependency it would be, most likely,
through a direct dependency.
Note that I definitely don't oppose to the idea of integrating such a
mechanism -- I do see the value. The question is if it should be the
default or not (Bundler is opt-in after all), taking into account for
example how well it interacts with branches and different use cases. I'm
quite open there, but I first have to play that through with all of my
stuff before I can voice an opinion.
Bundler is required when using Ruby on Rails. I just don't want
everything to break at random just because it's a month later a new
version of a package is released.
--
/Jacob Carlborg
