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 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)

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