On Mon, 14 Apr 2014 22:10:02 +0200, Sönke Ludwig wrote:
At this point I'm convinced that always using versions is the way to go.
Just tagging a new v0.0.x or something similar after a couple of days or
after each feature/important bug fix is trivial and helps a lot to at
least let any dependent libraries be stable as long as they target a
specific version.
I disagree. Consider DerelictSDL2. My plan for it (and most of the Derelict packages) is for release versions to mimic the version of SDL which the binding was created against. That's the only sensible way for me to handle it. The reasoning is that newer versions of SDL sometimes add new functions. Once I update the binding, then that version of the binding can no longer load older versions of the SDL library. Now, the latest release is SDL 2.0.3. Let's assume that someone finds a bug in the 2.0.1 binding. If I were using tags, there would be no way for anyone using the 2.0.1 binding to get the update without getting all of the new stuff from the later versions as well, meaning they would also have to change their app's dependency to the latest version of SDL2 when there's really no need to do that. By using branches, I can ensure that Derelict users can require the minimum version of SDL2 they want for their apps and not force them to use the latest version.
In other words, if support for branch-based dependencies is dropped, the entire structure of DerelictOrg is broken and I'm back to the bad old days of breaking people's apps every time they update Derelict. I moved to a dub-based, multi-repository framework in order to fix that :)