RejectedSoftware Forums

Am 21.08.2014 16:51, schrieb Sergei Nosov:

Hi!

At some point dub has deprecated branch dependencies and now I get the following warnings:

WARNING: A deprecated branch based version specification is used for the dependency libevent. Please use numbered versions instead. Also note that you can still use the dub.selections.json file to override a certain dependency to use a branch instead.
WARNING: A deprecated branch based version specification is used for the dependency vibe-d. Please use numbered versions instead. Also note that you can still use the dub.selections.json file to override a certain dependency to use a branch instead.
WARNING: A deprecated branch based version specification is used for the dependency libev. Please use numbered versions instead. Also note that you can still use the dub.selections.json file to override a certain dependency to use a branch instead.
WARNING: A deprecated branch based version specification is used for the dependency openssl. Please use numbered versions instead. Also note that you can still use the dub.selections.json file to override a certain dependency to use a branch instead.

(...)

So, my question is: since the only version of these libraries (libevent, libev, openssl) in package registry is master, what is the recommended way to specify those as dependencies to fix the warnings? I assume there's got to be some solution since you cannot build a vibe-d project without those libraries.

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.

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.

Hey, I've just looked at the official bindings (https://github.com/D-Programming-Deimos) and it seems Andrei is the member of this group. I would assume that he has administrative rights and also that he will be completely OK to add you as a member, so you could fix these issues in the mainstream repos.

Have you considered asking him about it?

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".