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@gmail.com wrote:
On Mon, Oct 14, 2013 at 11:57 AM, Robert Goldman rpgoldman@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.