Am 21.08.2014 17:35, schrieb Sergei Nosov:
On Thu, 21 Aug 2014 17:08:55 +0200, Sönke Ludwig wrote:
Really the only way is for those projects to tag a fixed version. I've
opened a ticket, but unfortunately didn't get a reaction, yet. Since I'm
managing those repositories on code.dlang.org, I'll probably start
pointing them to my own fork (with tags) instead of the official ones.Ok, good to know.
As a follow-up question, do you think it is feasible to make 'master' branch a special case, like - it will be the only branch you can specify instead of version.
This would in theory be the only feasible way to keep support for
branches in a logical/consistent way, but it would really just be an
awkward special case (also with other VCSs using different names for the
main branch!). There is also a number of projects already that use other
branches for their main development, so they would still have reason to
complain.
It would be a simple alternative to making 0.x tags all the time.
The problem is that even 0.x tags are important to have so that
dependent projects don't constantly break without good countermeasures
(especially useful together with dub.selections.json). The only
alternative would be to also support specific commit SHAs, but those
wouldn't allow to use relational comparisons and are kind of specific to
GIT/HG.
On one hand, I believe it would be convenient, simple and intuitive. A couple of other guys on the forum claimed that they're using this approach. Also, I would assume that a lot of programmers will be at least surprised when they find out you can't do that.
On the other hand, version tags rule is not really hard to follow and it also mildly teaches project maintainers some "ethics".
What is your thinking about it?
I think it is very important that we make sure that the ecosystem that
is built up is solid. History has shown that most people (round 70% of
the repositories) didn't version tag their packages at all when it
wasn't enforced by the registry. This led to a completely fragile system
where you often had no chance to pick a combination of dependencies that
worked together properly. And also no chance to avoid your project
breaking randomly when dependencies introduced changes on ~master.
After having though a lot about this problem complex, we simply found no
other solution than to completely avoid branch dependencies. The overall
system is also still extremely convenient for package maintainers
compared to most other package systems, where you have to explicitly
upload version snapshots instead of simply using "git tag".