Re: [racket-dev] Packaging
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 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Packaging
Good point Jay 2011/2/19 Eli Barzilay e...@barzilay.org: 5 hours ago, Jay McCarthy wrote: 2011/2/18 Jos Koot jos.k...@telefonica.net: For a simple windows 7 user as I it is rather difficult to use command line instructions. I plead for an easy to use gui for making contributions. I think this is orthogonal to the project, but I do mention how important it is to have an easy way of getting packages post-installation. I was imagining that this would be a separate GUI tool that was auto-launched on Windows installation and suggested on first launch of DrRacket. General reminder: when you're at the first launch step, you're already beyond the point of adding installation wide content. You're some student in some class that is annoyed at their sysadmins not installing something, and annoyed at the constant popups since they're working on public machines that are getting wiped on every logout. Or you're a sysadmin that gets annoyed at the fact that the need to interact with the installer. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Packaging
Do you mean to inherit Planet's current version number semantics? Uh. 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
Re: [racket-dev] Packaging
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? Uh. 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 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Packaging
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? Uh. 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
Re: [racket-dev] Packaging
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? Uh. 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
Re: [racket-dev] Packaging
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? Uh. 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
