On Sun, Sep 12, 2010 at 10:22 PM, Robert Goldman <rpgold...@sift.info>wrote:
> On 9/12/10 Sep 12 -1:55 PM, Vsevolod Dyomkin wrote: > > On Sun, Sep 12, 2010 at 8:09 PM, Robert Goldman <rpgold...@sift.info > > <mailto:rpgold...@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 with > asdf: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 fondest > dreams > > 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 am > looking > > 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 needs > to > > be very, very stable (see the paper Faré and I wrote about ASDF 2 > > development for a more thorough presentation of the need for > stability). > > > > > > 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 are > at > > 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 > >
_______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel