[asdf-devel] versioning [was Re: asdf verbosity]

[Daniel Herring]

On Wed, 27 Apr 2011, Faré wrote:

> On 27 April 2011 12:57,  <dherring at tentpost.com> wrote:
>> These are probably good things, but as Zach mentioned, recently ASDF has
>> started dragging users through internal development.  Its a gripe I have
>> about Slime and some other key libraries, so you are in good company, but
>> I cannot follow "the bleeding edge" as a matter of habit.
>>
> Uh - I've been trying my darned best to make "release" versions stable,
> e.g. 2.010, 2.011, 2.012, 2.013, 2.014. I may not have been as successful
> at it as I'd like, but so far as I can tell, all the complaints (which
> are justified and most welcome) had to do with non-release versions, e.g.
> 2.014.8, etc.

In a nutshell, things like changes to inputs (enforcing contracts), 
outputs (changing what's printed) and internal behaviors (e.g. path names 
vs objects) are very sensitive in ASDF.  There are many users of the 
system, and a good number were tuned to the implementation instead of any 
specification.  ASDF's design leaks all sorts of details.

While you are tagging "minor" releases roughly once a month, since there 
are no separate trunk/release branches, all the changes appear in each 
month's release.  Thus I think you either need to restrict yourself to 
truly minor changes (not good for development), only make major releases 
once a year or so, or split development and only backport critical fixes 
and clean API extensions to the release branch.

In short, I wasn't really aware that people were actively seeking 
enhancements, but I have seen a number of potentially breaking changes, 
and the current development cycle means people have to catch them every 
month.


>> I think many recent ASDF changes have been good, but they are falling into
>> the major release category.  They can't be going into monthly Quicklisp or
>> SBCL updates or (your favorite distribution channel here).
>>
> Do you call 2.014 vs 2.011 "major"?

By number, no.  By content, ...

>From a quick scan, here are a few good-looking changes that might count as 
major.

eb1ed61 Substituted (default-directory) for *default-pathname-defaults*
09b9b8a Binding of *default-pathname-defaults*
[special variables in CL have high visibility]

2.012.2: cleanup name of cache directory for clisp (remove trailing dash)
[the user should be told to rename or delete the old directory]




>> Its just that the end user should have to be involved.
> I don't understand what THAT means.

I think I meant "should not have".  In other words, end users should be 
able to trustingly accept minor and micro versions, generally without even 
reading a changelog.  Their grey matter should only need to kick in on the 
major release cycles.  This also allows other people (e.g. debian or sbcl) 
to safely make the upgrade choice for them.

- Daniel