On Wed, 27 Apr 2011, Faré wrote:
On 27 April 2011 12:57, dherring@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