[asdf-devel] 3.0.2.21

[Faré]

On Mon, Oct 14, 2013 at 11:57 AM, Robert Goldman <rpgoldman at sift.net> wrote:
> Faré wrote:
>> Robert: can I commit this asdf-package-system branch now, before the
>> 3.0.3 release? It's only additive features [...]
>
> I would sort of prefer not to, because I would like people to require
> ASDF 3.1 when using asdf package systems.
>
I both agree on the goal and disagree on the means:

 1- Yes, it would be nice to have an #+asdf3.1 feature
  and encourage people to conditionalize on it
  their use of recent features not present in 3.0.0.

 2- On the other hand, the only way to really iron out the kinks
  is to get the feature out early, and get more people to try it.
  If we wait for all bugs to be fixed to release, we'll never release,
  and we'll never get them fixed.
  This weekend debugging session on Windows found plenty of bugs
  (that prove that there are no CL hackers using run-program much
  on Windows, and not just uiop's wrapper, but the underlying thing).
  There were also bugs in some use cases of with-temporary-file,
  of for various open file utilities on LispWorks (I just discovered
  that you better use lw:simple-char rather than character if you
  specify :external-format :utf-8).

 3- After a week of using it, I found many small kinks in that branch,
  that I resolved. More eyes could have found them earlier, and could
  have found the kinks that I still haven't seen. If there are such
  bugs lurking around, I really would like them fixed before we declare
  "yes, you can really trust this feature to be there and solid if
  the asdf3.1 feature is present."

> I don't like instituting new API features without a reliable way to
> detect whether or not your version of ASDF supports them.  If I let this
> slip out in ASDF 3.0, then if people start using the feature in the
> wild, they CANNOT conditionalize it on ASDF version being greater than
> 3.1.  Hence my preference to keep it out of 3.0.3.
>
When I introduced the :around-compile, :compile-check, :force-not,
a working :force (sys1 sys2), classes cl-source-file.cl & cl-source-file.lsp,
quicklisp compatibility, a *working* :defsystem-depends-on or :encoding,
I didn't add a new feature (ok, for :encoding, there's :asdf-unicode
when it's actually useful). Rather, users could either
:depends-on ((:version :asdf "2.23")) or
#.(if (fboundp 'asdf::some-function) ...)
Eventually, but not initially, I could just start using #+asdf3
for my uses of these features.

I propose that the same be true for the asdf-package-system.
For now, people can #.(if (find-class 'asdf::package-system nil) ...)
and in a few weeks or months, they can instead #+asdf3.1

> However, I sympathize with your desire to kill the topic branch.  So how
> about this:
>
> I will run the tests again today on head, on Mac and Linux.  If the
> tests all pass for me, I will release 3.0.3, and we will move to 3.1.0.
>
> I was holding off, hoping for a judgment about 3.0.3 compatibility with
> Quicklisp, but don't want to continue to push the branch maintenance
> cost onto you.
>
Works for me, too.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Every program has at least one bug and can be shortened by at least one
instruction — from which, by induction, one can deduce that every
program can be reduced to one instruction which doesn't work.