On Fri, 02 May 2014 09:25:03 GMT, Mike Parker wrote:
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 :)
If proper SemVer versions are used, there is no problem. This will mean that there is not necessarily a one-to-one correspondence between the original version digits and those of the binding, but it will naturally support bugfix releases for the original library, as well as for the binding. The "build metadata" part of the version can be used to denote the exact SDL version the binding is based on (will be ignored when comparing versions). Example:
SDL 2.0.1 => DerelictSDL 1.0.0+sdl-2.0.1
SDL 2.0.1 + bugfix 1 => DerelictSDL 1.0.1+sdl-2.0.1
SDL 2.0.1 + bugfix 2 => DerelictSDL 1.0.2+sdl-2.0.1
SDL 2.0.2 => DerelictSDL 1.0.3+sdl-2.0.2 (assuming SDL 2.0.2 contains only bugfixes and is fully API/ABI compatible)
SDL 2.0.3 => DerelictSDL 1.1.0+sdl-2.0.3 (assuming SDL 2.0.3 contains only backwards compatible changes)
SDL 2.1.0 => DerelictSDL 2.0.0+sdl-2.1.0 (breaking changes, could be maintained in parallel on a separate "2.1.x" branch)
Instead of choosing a branch, the user of the library then uses "derelict-sdl": "~>1.0.0" or "derelict-sdl": "~>1.0" to get only bug fix or backwards compatible releases. The good thing then is also that people can do "derelict-sdl": "1.0.2" or "derelict-sdl": ">=1.0.0 <=1.0.2", should there be any unintended breaking changes in 1.0.3.
Of course other translation schemes can also be used, if the original version scheme permits it, such as always using the same first two version digits as the original library.