OTOH, it's probably A Bad Thing if you depend on a system for something you are doing, and don't know what license it uses.
Well, we haven't codified any format for :license. I suppose we could adopt the nomenclature used by Debian. Except what in Lisp circles goes by the name "MIT" (as notably used by ASDF itself) in Debian-speak is called "Expat". Also, we don't have a story for multi-licensed code either. For instance, I have code under LLGPL or bugroff, or BSD or bugroff.
But that's why I created a special class of CONDITION for this case -- so you can muffle it if you don't care. It would be nice if there was some way to detect the distinction between internal systems (fix them!) and external systems (muffle).
At ITA, we started with muffling the external systems, but quickly enough decided to fix them instead; code quality matters for libraries we depend on, too. But we did have a list of style-warnings to muffle and some of them were based on dependencies indeed.
I'll push my topic branch today. It needs a test script, and I'd like to make it skip signaling on "slashy" subordinate systems, but I'd love comments in the meantime.
I'm concerned about postponing this because I don't see implementations -- *especially* the commercial ones -- picking up ASDF revisions quickly.
I'm not sure how postponing will make implementations pick ASDF up faster. The frustration about that next feature not going to make it to implementations nearly as fast as you'd like is going to be with you no matter what. Count one year for adoption by "early adopters", and two years for ubiquitous adoption. That was the approximate delay for both ASDF 2 and ASDF 3. Delaying a release by a few weeks doesn't make sense in contrast.
I figure it's rate limited, not time limited. I.e., I get a limited number of opportunities to have the implementations pick up an ASDF, so I'd like to pack in as many fixes and enhancements as possible.
I'm not sure that's correct. IIUC, there are three kinds of implementations: 1- those have their own slow release schedule, independent from ASDF's, and our goal is to convince them to include "update ASDF" in their release checklist. 2- those that do not have a release schedule, and our goal is to convince them to "update ASDF" in a timely way after it is released. 3- Implementations such as SBCL that release regularly and often, and couldl adopt either strategy (but, in the case of SBCL, doesn't really). Release fatigue would only happen if you released so often that you annoy those who follow strategy #2. Maybe that's what happened with SBCL. Somehow, I don't see this happening with ASDF anymore, unless you have hidden development plans.
That said, it'd be nice if the following implementations upgraded more often: Allegro, CLISP, ECL, SBCL. The former two haven't reached ASDF 3.1 yet.
My copy of Allegro is at 3.1.4.3. They have issued at least two ASDF patches since the 9.0 release.
My allegro express is stuck at 3.0.2.3, but maybe the issue is a failure of the ./update.sh script, which may be due to my Ubuntu not supporting the 32-bit graphic libraries used by Allegro.
clisp seems to have given up releasing.
I've seen a call for new maintainers relayed by Xach.
I'm excited to see ECL get revitalized now that it has new maintainers.
Yes. And it has a relatively recent ASDF 3.1.2, though 3.1.4 would be better.
My SBCL is at 3.1.3. I think 3.1.4 is solid enough that it should be updated there.
I've bugged SBCL hackers many time since last october, to no avail. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org In reviewing the history of the English Government, its wars and its taxes, a bystander, not blinded by prejudice nor warped by interest, would declare that taxes were not raised to carry on wars, but that wars were raised to carry on taxes. — Thomas Paine, "Rights of Man"