Robert Goldman <rpgold...@sift.net> writes:
> On 6/16/15 Jun 16 -9:31 AM, Didier Verna wrote:
>> Robert Goldman <rpgold...@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:
>
> 1. Further complicating an ASDF that's already grown far larger than the
> original
>
> 2. 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:
>
> 1. 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).
>
> 2. 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))
--
__Pascal Bourguignon__ http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk
