The dictatorship of versioning

[Pascal J. Bourguignon]

Robert Goldman <rpgoldman at sift.net> writes:

> On 6/16/15 Jun 16 -9:31 AM, Didier Verna wrote:
>> Robert Goldman <rpgoldman at 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