[asdf-devel] 3.0.2.21

[Pascal Costanza]

Could you please distinguish between stable and unstable releases. It's fine to ask the CL community to help with finding and fixing bugs, but there are situations where this can be a real showstopper, especially when working against deadlines. You have been very aggressive in the past at pushing out buggy versions of ASDF into compilers and quicklisp, and this can create real headaches. I think these versions should only get stable releases, and people interested in bleeding edge features can then ask for the unstable releases explicitly.

Please!!!


Pascal

Sent from my iPad

> On 14 Oct 2013, at 19:17, Faré <fahree at gmail.com> 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
> 
>> 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.
>