Robert Goldman rpgoldman@sift.net writes:
On 6/16/15 Jun 16 -9:31 AM, Didier Verna wrote:
Robert Goldman rpgoldman@sift.net wrote:
Now: a request for management purposes: Didier, would you be so kind as to describe the proposal (I think cut and paste out of your earlier emails would do admirably) in a ticket on launchpad.net?
OK. I will also add Pascal's suggestion to have both a canonical and human readable version slot.
I'm inclined to put that one on the side, mostly because I find Pascal's suggestion far less appealing. I see two problems with this suggestion:
- Further complicating an ASDF that's already grown far larger than the
original
- Duplication of function. Software engineering is replete with
failures where programmers are required to state the same information twice (e.g., comments or javadoc together with source code). Inevitably, the multiple forms of redundant information stray from each other. So what happens when the programmer updates the human readable version and not the canonical version, or vice versa? Wouldn't it be better to functionally derive one of these two forms from the other? E.g., (defgeneric formatted-version (component version-spec))
I am also disinclined to add something like the proposed
:version-major 1 :version-minor 0 :version-release 42
There are two reasons for my reluctance:
- I don't think it's necessary. If those slots are desired, it should
be possible to extend the SYSTEM class for specific systems in order to accommodate these new flags, without changing the core of ASDF.
If that's *not* true, then we should fix the protocols to make it true (and I'd welcome another ASDF ticket to this effect).
- Adding this proliferation of version sub-flags to core ASDF seems
undesirable for a number of reasons:
- It would potentially radically complicate the parsing of systems.
- Developers are already disinclined to put in :version specifiers:
making the specification more complicated seems unlikely to improve that situation.
- Adding more (and more verbose) flags would further detract from
readability of DEFSYSTEM forms by burying their true content in ever more metadata.
- Finally, I don't see that this provides advantage over :version
"1.0.42" together with functions for manipulating said version string (e.g., (defgeneric major-version (component version-string) ).
In sum, this seems like a lot of new hair for limited payoff to the community.
Agreed, spliting version is bad.
On the other hand, using a list of integer as version could be an improvement, since it would make it clear what a version is.
:version (1 0 42)
Of course, Didier already perverted the idea by writing something like:
:version (1 3 :beta 4 "Release Name")
In cesarum, I solved the problem with the heuristic of "parsing" and filtering out non-integers from the version strings, to obtain a normalized version number.
version ::= [a-z]* integer ('.' integer)* ('.' [a-z]+)? (+|[a-z]|'r' integer)? ('(' /.*/)?
cl-user> (use-package :com.informatimago.common-lisp.cesarum.version) t cl-user> (version (lisp-implementation-version)) (1 10 16196) cl-user> (version "1.10-r16196.beta.42.yosemite (x86) happy hacking.3") (1 10 16196) cl-user> (version "1.10.4") (1 10 4)
(mapcar (function version) '("1.3.1" "Version 1.10-r16196 (LinuxX8664)" "2.49+ (2010-07-17) (built 3603386203) (memory 3603386298)" "20d (20D Unicode)" "13.5.1" "1.0.57.0.debian")) --> '((1 3 1) (1 10 16196) (2 49 1) (20 3) (13 5 1) (1 0 57 0))