[asdf-devel] 3.0.2.21

Robert P. Goldman rpgoldman at sift.info
Mon Oct 14 18:58:30 UTC 2013


Faré wrote:
> 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

No, I don't want us to get into that position of users having to go back
and change their system definitions later.

I think it's just simpler to push out 3.0.3 today, absent the feature,
and then our users can  :depends-on (:version :asdf "3.1") or #+asdf3.1
right away.

It should only be a matter of hours before we can start 3.1.0.1 and kill
this pesky branch.

Best,
Robert




More information about the asdf-devel mailing list