In that case, I'll explain the suggestion more for everyone else.
----------------------------------------
The first patch lets you optionally include a version in a package's
"info.rkt", like
(define version "1.0")
If you don't provide a version, the default version for a package is
"0.0". A version number must have the same shape as a Racket version
number, but the way that versions are assigned to a package is up to
the package author.
The only use of package version numbers is in a dependency. For
example, you can write
(define deps '(("hello" "1.3")))
in a package's "info.rkt" file if it needs at least version "1.3" of
"hello". If the installed "hello" package has a version less than
"1.3", then `raco pkg install' or `raco pkg update' will complain
and/or attempt to update the "hello" package.
You can use "racket" as a package name if you want to declare a
dependency on a particular version of Racket --- in which case `pack
pkg install' can only complain if the version is higher than the
running Racket.
The package name resolver (formerly package name service) pays no
attention to a package's version. Updates are still based on package
checksums, not package versions.
The intent of a package version is to reflect available features, as
opposed to mere revisions of the code. Typically, a version number
should increment when new features are added to a package, so that
other packages can declare a dependency on the feature. I do not
suggest incrementing the version number with every bug fix or other
revision, but the choice is up to each package author.
Package versions numbers do *not* address the problem of
backward-incompatible changes to a package, since versions in
dependencies are always lower bounds. Package authors should avoid
backward-incompatible changes and/or create new packages.
----------------------------------------
The second patch includes the *Racket* version number in a request that
is sent to a package name resolver. The intent is that a package author
can support old Racket versions (while making changes that depend on
new Racket features) by providing different mappings of a package name
for different Racket versions.
I imagine that the PLT PNRs will by default map a package name the same
way for all Racket versions. A package author will then have some way
of specifying an alternative for older versions. That is, the package
author will have to do some extra work to support old versions, but
only when making changes that can't work in old versions.
I might guess wrong about how we'll use the Racket version in a PNR,
but I'm more confident that we'll be able to do something good as long
as the Racket version is part of the protocol.
At Fri, 21 Dec 2012 12:35:06 -0700, Jay McCarthy wrote:
> Sorry for not getting back to you faster. I think the changes are
> great. Thank you.
>
> Jay
>
> On Fri, Dec 21, 2012 at 11:56 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote:
> > I pushed these by accident; they're still just suggestions.
> >
> > At Fri, 21 Dec 2012 13:53:10 -0500, mfl...@racket-lang.org wrote:
> >> 0e140a8 Matthew Flatt <mfl...@racket-lang.org> 2012-12-20 11:07
> >> :
> >> | planet2: versions for dependencies
> >> [...]
> >>
> >> 5259f15 Matthew Flatt <mfl...@racket-lang.org> 2012-12-20 12:05
> >> :
> >> | planet2: include the Racket version number in a PNR request
> >
> > _________________________
> > Racket Developers list:
> > http://lists.racket-lang.org/dev
>
>
>
> --
> Jay McCarthy <j...@cs.byu.edu>
> Assistant Professor / Brigham Young University
> http://faculty.cs.byu.edu/~jay
>
> "The glory of God is Intelligence" - D&C 93
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
