Am 30.11.2015 um 08:20 schrieb Sven Panne:
Personally, I don't consider littering my code with version numbers as "little effort".
Indeed it isn't. The effort could be reduced with proper tool or language support.
Stuff like this should be specified outside of the source code IMHO.
Well, sort-of. Let's assume semantic versioning: major version number changes for incompatible API changes, minor for downwards-compatible API changes, and tertiary ("milli") version number changes for API-unaffecting changes. So if your code calls into foo-3.4.1, you shouldn't have to worry whether it is actually being used with foo-3.4.2, or foo-3.5.0. However, you need to say foo-3 somewhere, inside your sources, because your code may break with foo-4.x.x. One issue I'm having with semantic versioning is that supposed-to-be-compatible library updates tend to be actually incompatible, often in subtle ways, so the library is released with a millversion change but that's a mistake (and lieing towards the application that's assuming an unchanged API). It's a big issue with imperative languages, where implementation details can leak via state. In Haskell, I suspect that (non-)termination behaviour is a similar potential implementation leak, though there's less opportunity for that to actually happen since the library would need to have lots of complicated, potentially infinite data structures hidden below opaque types. Regards, Jo