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