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