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
