I am aware of the external versions, but since I can't put them in a require spec to identify the package I want, they aren't terribly useful as an identifying feature of a package.
Carl Eastlund On Tue, Feb 22, 2011 at 4:34 PM, Robby Findler <ro...@eecs.northwestern.edu> wrote: > Thanks for clarifying. And I'm sure you must know about it and I'm a > bit afraid to even bring it up, but you might want to use planet's > external version feature. > > Robby > > On Tue, Feb 22, 2011 at 3:32 PM, Carl Eastlund <c...@ccs.neu.edu> wrote: >> I am saying we should use something that is not called "version >> number". On the IRC list I have suggested -- without too much thought >> behind it yet -- that we construct an "upgrade graph"; package >> maintainers can specify which package can be thought of as an >> automatic improvement on another, and some appropriate part of the >> Planet mechanism can therefore follow a chain of these links to find >> the best available candidate for a require. That allows package >> names, version numbers, and other string-based user-readable >> package-identifying features to be uninterpreted, and written however >> the maintainer wants. >> >> Carl Eastlund >> >> On Tue, Feb 22, 2011 at 4:06 PM, Robby Findler >> <ro...@eecs.northwestern.edu> wrote: >>> Carl: your message is unclear to me. Are you saying that attempting to >>> solve the problem of matching up require requests with available >>> versions of software packages is hopeless and we shouldn't attempt it, >>> or are you saying that we should use something that is not (literally) >>> called "version number" or are you saying something else? >>> >>> Robby >>> >>> On Tue, Feb 22, 2011 at 3:01 PM, Carl Eastlund <c...@ccs.neu.edu> wrote: >>>> Do you mean to inherit Planet's current "version number" semantics? >>>> Ugggghhhhh. Assigning a fixed structure and semantics to version >>>> numbers was one of the worst things Planet did. Dracula is up to >>>> 8:18, and goodness knows what that means. It does not mean there have >>>> been 8 significantly different versions of Dracula, such that I gave >>>> the release bigger fanfare than usual. It means there were 8 times >>>> when some potential incompatibility between releases occurred to me >>>> between the time of package creation and the time of upload. That >>>> should not be how version numbers are determined. It is not at all >>>> clear to me that version numbers should serve as an automatic metric >>>> of compatibility or upgrade-ability; let's either come up with a >>>> metric that is more to the point, or stop trying so hard to enforce >>>> things like "no compatibility regressions" that are often hard to >>>> detect in the first place. >>>> >>>> Carl Eastlund >>>> >>>> On Tue, Feb 22, 2011 at 3:37 PM, Jay McCarthy <jay.mccar...@gmail.com> >>>> wrote: >>>>> I don't feel strongly about this and you seem to, so supposing we >>>>> support any conflicting installations, it makes sense for Planet 2.0 >>>>> to have both major and minor versions. >>>>> >>>>> Jay >>>>> >>>>> 2011/2/19 Robby Findler <ro...@eecs.northwestern.edu>: >>>>>> On Sat, Feb 19, 2011 at 10:18 AM, Robby Findler >>>>>> <ro...@eecs.northwestern.edu> wrote: >>>>>>> It looks to me like you there is relevant, important metadata that >>>>>>> you're making someone fold into an implicit place instead of an >>>>>>> explicit one. >>>>>>> >>>>>>> Will you have a convention for these? What if I decide to call mine >>>>>>> "libgtk2.0" and someone else calls theirs "somepackage-2"? That >>>>>>> doesn't seem good fo >>>>>> >>>>>> [ Sorry; got distracted here and forgot to come back. ] >>>>>> >>>>>> That doesn't seem good for users who are trying to find packages. >>>>>> Especially if I were to call mine "2-somepackage" (you may think this >>>>>> far fetched, but if you look you should find an example of this in our >>>>>> current collection tree....) >>>>>> >>>>>> Robby >> > > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev