3 ms·

I have one single question: how does calver solve any of these problems?

by syrrim 8y ago

geofft 8y ago
Differently in different projects, but usually adopting CalVer is a sign that, unlike with SemVer, you're not using the version number to connote backwards compatibility. Code that continues to be accessible via the same path/name/etc. is always backwards-compatible (i.e., if a consumer application would compile or run fine on a newer version without errors, there aren't hidden semantic changes). If you need to make a backwards-incompatible change, you handle it in some means other than the version number, usually either by renaming the project, the import path, or the function. Looking at the example CalVer projects: Ubuntu follows this model because it's the model of basically all UNIX distributions, that a particular command name doesn't change meaning / API without either a deprecation cycle or an explicit action from the sysadmin. If a command changes incompatibly (e.g., Python 2 to Python 3), it gets a different name (e.g., /usr/bin/python to /usr/bin/python3). If a library changes incompatibly, it either uses symbol versioning infrastructure to provide old and new versions of the function (e.g., fmemopen@GLIBC_2.2.5 is now provided by libio/oldfmemopen.c, and the fmemopen@GLIBC_2.22 implementation, which fixes tons of bugs and drops questionable features, is only visible to programs compiled on a system with glibc 2.22 or newer), or the library itself has a new filename (e.g., at some point libcurl.so.3 became libcurl.so.4). Therefore, code that compiled and ran fine on, say, Ubuntu 16.04 should generally be expected to compile and run fine on Ubuntu 18.04, or less commonly, not run at all with a clear error up front about the specific missing functionality. Twisted, youtube-dl, and pytz follow a similar model. Code written against them years ago should generally continue to work; the version number provides information on new features, not on deprecations. Teradata UDA is different, but it follows the underlying CalVer philosophy of breaking changes being something to avoid. (But it uses a year and month to indicate an API compatibility level, which isn't how the rest of the CalVer projects use dates.) So the answers to my bullet points for CalVer are generally ">=", "Rename the functionality, do not ever redefine an existing name", "Newest compatible dependency is fine and you should definitely have integration tests," and "Diamond dependencies to different versions aren't a problem, diamond dependencies to different names e.g. libcurl.so.3 and libcurl.so.4 are discouraged but should work".

I have one single question: how does calver solve any of these problems?

by syrrim 8y ago

I have one single question: how does calver solve any of these problems?

Differently in different projects, but usually adopting CalVer is a sign that, unlike with SemVer, you're not using the version number to connote backwards compatibility. Code that continues to be accessible via the same path/name/etc. is always backwards-compatible (i.e., if a consumer application would compile or run fine on a newer version without errors, there aren't hidden semantic changes). If you need to make a backwards-incompatible change, you handle it in some means other than the version number, usually either by renaming the project, the import path, or the function. Looking at the example CalVer projects: Ubuntu follows this model because it's the model of basically all UNIX distributions, that a particular command name doesn't change meaning / API without either a deprecation cycle or an explicit action from the sysadmin. If a command changes incompatibly (e.g., Python 2 to Python 3), it gets a different name (e.g., /usr/bin/python to /usr/bin/python3). If a library changes incompatibly, it either uses symbol versioning infrastructure to provide old and new versions of the function (e.g., fmemopen@GLIBC_2.2.5 is now provided by libio/oldfmemopen.c, and the fmemopen@GLIBC_2.22 implementation, which fixes tons of bugs and drops questionable features, is only visible to programs compiled on a system with glibc 2.22 or newer), or the library itself has a new filename (e.g., at some point libcurl.so.3 became libcurl.so.4). Therefore, code that compiled and ran fine on, say, Ubuntu 16.04 should generally be expected to compile and run fine on Ubuntu 18.04, or less commonly, not run at all with a clear error up front about the specific missing functionality. Twisted, youtube-dl, and pytz follow a similar model. Code written against them years ago should generally continue to work; the version number provides information on new features, not on deprecations. Teradata UDA is different, but it follows the underlying CalVer philosophy of breaking changes being something to avoid. (But it uses a year and month to indicate an API compatibility level, which isn't how the rest of the CalVer projects use dates.) So the answers to my bullet points for CalVer are generally ">=", "Rename the functionality, do not ever redefine an existing name", "Newest compatible dependency is fine and you should definitely have integration tests," and "Diamond dependencies to different versions aren't a problem, diamond dependencies to different names e.g. libcurl.so.3 and libcurl.so.4 are discouraged but should work".