On Sun, Sep 12, 2010 at 10:22 PM, Robert Goldman rpgoldman@sift.infowrote:
On 9/12/10 Sep 12 -1:55 PM, Vsevolod Dyomkin wrote:
On Sun, Sep 12, 2010 at 8:09 PM, Robert Goldman <rpgoldman@sift.info mailto:rpgoldman@sift.info> wrote:
On 9/12/10 Sep 12 -11:48 AM, Vsevolod Dyomkin wrote: > Hi, Some random comments........
2. If the rational version policy is the numbering scheme I found by googling, I don't believe it is compatible withasdf:version-satisfies.
I would suggest we avoid adopting a policy that doesn't meet that constraint.Last time I looked, version-satisfies quite-happily handled exact versions, like "1.2.3", which also comply with the "rational" policy. At the same time, current versions, like 2.103 are actually 2.1.3 in disguise, which is a little annoying. Yet, the biggest benefit of the rational policy (or at least some policy) is that it's predictable.
I don't believe that is correct. Here is a line I have ripped from version-satisfies-p, which seems to clearly show that 2.103 is (2 103) not (2 1 3):
ASDF(76): (mapcar #'parse-integer (split-string "2.103" :separator ".")) (2 103)
And that is what's annoying, since actually (semantically) 103 is meant as 1.3, no?
3. Is this bi-monthly release policy wrt ASDF 3? In my fondestdreams
ASDF2 is getting stable and the ASDF 2 release cycle should be "very rarely, never in the limit." I say this not just because I amlooking
forward to ASDF 2 being done, but also because ASDF is critically foundational to the entire open source CL community. In order for members of this community to be able to share work, ASDF's API needsto
be very, very stable (see the paper Faré and I wrote about ASDF 2 development for a more thorough presentation of the need forstability).
Rarely a release should break backwards compatibility. But from what I see now, there's quite a lot of fixes to ASDF (at least a couple each month), and I don't forsee the change to such situation.
I certainly hope you are wrong in thinking this won't change, but fine.
I think we are still going to want a release policy for ASDF 3 and ASDF 2 separately, with the ASDF API being stable over ASDF 2 releases.
> - finish creating a comprehensive test-suite, and organize some > automatic testing process This would be very good. BTW, I have just discovered that there areat
least three different ways to start CCL, and only one of them is currently exercised by our test suite. > - move development to github, where there is some rather > convenient infrastructure, like issue tracking (leaving a mirror on > common-lisp.net <http://common-lisp.net> <http://common-lisp.net>) Is there some reason that common-lisp.net <http://common-lisp.net> + launchpad is unsatisfactory?It's much less integrated and more clumsy (I filed several bugs through launchpad myself and don't like the experience). It seems, that github is a much friendlier place for that, and it is developing pretty fast. Yet, I don't think, that it is critical, so if other contributors would like to stay with the current variant, I don't object.
I am just feeling the need for some stability, having been through CVS and git already (and the git transition was pretty bumpy). Getting all the information OUT of launchpad and into a different issue tracker seems painful. However, if someone wants to take the trouble of actually porting all the launchpad data, who am I to object?
Best, r