I want to highlight another tool to deal with versioning.
19.11.2013, 23:41, "Robert P. Goldman" rpgoldman@sift.info:
two versions of the same library on the same machine is quite feasible, and indeed I do this myself, every day. I have different source trees for different projects, and with each source tree is associated a different ASDF configuration.
This is not a futuristic "wouldn't it be nice if..." situation, either: it's a simple requirement of my daily work environment. E.g., I have projects that rely on different versions of FiveAM (they are hosted differently, so it's not just a matter of demanding that everyone upgrade -- some I run, some I don't).
I did that too. I had a config file vermap.lisp which puts directories of the libary versions I need to ASDF central registry.
So, when we say :depends-on (#:fiveam) we have an external configuration which specifies then exact version of fiveam to be loaded.
The external configuration is a flat mapping: (:name :chunga :ver "0.4.3") (:name :cl-base64 :ver "3.3.2") (:name :cl-cont :ver "0.3.4") (:name :cl-containers :ver "0.9.10") (:name :cl-fad :ver "0.6.2") (:name :cl-html-parse :ver "1.0")
I called such a mapping a "vermap" or a "libworld". I used different vermaps for different applications.
And Quicklisp uses this approach. Quicklisp dist version is a collection of releases, it specifies what exact release of fiveam is used by asdf:load-op "fiveam".
This approach is different from the case where each libary author specifies constrains for the library dependencies, and the library loader tries to find some versions which satisfy the constrains.
With the exact mapping we have a reproducible configuration. For example, my application startup script does (require-quicklisp :version "2013-01-28"), so that when the application is deployed on server, it works with exactly same library versions as it was tested on the development machine.
Developers can collaborate to assemble library version and share vermaps which are consistent and tested to work well together. They can be shared inside a company, or globally, like Quicklisp does.
Best regards, - Anton
ASDF was never equipped to resolve versioning constraints, just to check them. So yes, we need external tools to create assemblies of mutually-compatible library versions. Quicklisp is such at tool, and the only one being maintained at this point.
Otherwise, I agree that unless it is both intended and practically achievable that all useful clients should be updated to use the new API, it is bad taste to ever issue an incompatible version while keeping the same name.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The Miracle of the Thanksgivukah: the Turkey was supposed to be eaten up in one evening, but it lasted eight days.
On Thu, Nov 28, 2013 at 5:24 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
I want to highlight another tool to deal with versioning.
19.11.2013, 23:41, "Robert P. Goldman" rpgoldman@sift.info:
two versions of the same library on the same machine is quite feasible, and indeed I do this myself, every day. I have different source trees for different projects, and with each source tree is associated a different ASDF configuration.
This is not a futuristic "wouldn't it be nice if..." situation, either: it's a simple requirement of my daily work environment. E.g., I have projects that rely on different versions of FiveAM (they are hosted differently, so it's not just a matter of demanding that everyone upgrade -- some I run, some I don't).
I did that too. I had a config file vermap.lisp which puts directories of the libary versions I need to ASDF central registry.
So, when we say :depends-on (#:fiveam) we have an external configuration which specifies then exact version of fiveam to be loaded.
The external configuration is a flat mapping: (:name :chunga :ver "0.4.3") (:name :cl-base64 :ver "3.3.2") (:name :cl-cont :ver "0.3.4") (:name :cl-containers :ver "0.9.10") (:name :cl-fad :ver "0.6.2") (:name :cl-html-parse :ver "1.0")
I called such a mapping a "vermap" or a "libworld". I used different vermaps for different applications.
And Quicklisp uses this approach. Quicklisp dist version is a collection of releases, it specifies what exact release of fiveam is used by asdf:load-op "fiveam".
This approach is different from the case where each libary author specifies constrains for the library dependencies, and the library loader tries to find some versions which satisfy the constrains.
With the exact mapping we have a reproducible configuration. For example, my application startup script does (require-quicklisp :version "2013-01-28"), so that when the application is deployed on server, it works with exactly same library versions as it was tested on the development machine.
Developers can collaborate to assemble library version and share vermaps which are consistent and tested to work well together. They can be shared inside a company, or globally, like Quicklisp does.
Best regards,
- Anton
Developers can collaborate to assemble library version and share vermaps which are consistent and tested to work well together. They can be shared inside a company, or globally, like Quicklisp does.
we do that with the dwim.hu libs using darcs repos and tags.
every once in a while, i tag a version of all our repos that work well together with a tag like '2013-12-01', or sometimes '2013-12-01-some-project' when i'm tagging the state that is needed for a specific project. in darcs these tags can happily live by each other in the same repo in an unordered fashion.
as for the dependencies, we always use the repos of the dependencies, and we have a function that collects the repo state in the form of tag names, revisions, etc... and it can also generate a checkout script that can be used to clone the needed version of all the dependencies.
currently here:
http://dwim.hu/darcsweb/darcsweb.cgi?r=HEAD%20hu.dwim.home;a=headblob;f=/sou...
but it should move into some util location...