At Fri, 22 Aug 2014 09:13:52 -0400, Sam Tobin-Hochstadt wrote: > On Fri, Aug 22, 2014 at 8:53 AM, Matthew Flatt <[email protected]> wrote: > > The site > > > > http://pkg-build.racket-lang.org/ > > > > reports the result of a daily build of all packages that are listed at > > "pkgs.racket-lang.org". The builds use the current release of Racket > > (version 6.1), and the site includes documentation for packages that > > build successfully. > > What should happen for packages that require an unreleased version of > Racket (such as "misc1" and its dependencies)? Right now they fail to > build, but it would be nice to have documentation for them.
If there's a branch or commit of a package that works with v6.1, and if the author of the package registers that branch/commit as source of the package when requested for version "6.1", then the package-build service will pick up that branch/commit and the build can succeed. The package author can register a core-version-specific source at "pkgs.racket-lang.org" through the package-configuration dialog's "version exception" field. ---------------------------------------- Stepping back, there are different possible modes for working with Racket and packages: working with the very latest of everything, working with the most recent release of the Racket core but the latest versions of packages, working with a snapshot of packages taken at the most recent release, and so on. In general, the way to select a different mode is to use a particular package catalog. Different catalogs can implement different modes and policies. (A Racket distribution selects a mode through its default package-catalog configuration. For example, a distribution from "download.racket-lang.org" consults a catalog that supplies a snapshot of some packages and defers to "pkgs.racket-lang.org" for others. The subset of packages in the release snapshot is currently the packages that are in the main Racket repo, but that's evolving.) The "pkgs.racket-lang.org" catalog is mainly set up for "the very latest of everything", but it tries to provide "the latest that works for a particular Racket core version". The latter currently requires more work from package authors in the case that "latest for a core version" is not the same as "latest". The package-build service could similarly always build against the latest of everything. That would work well enough with the number of packages that we have now, but when there are 20 times as many packages, then I think it will be difficult for the build service to keep up when a widely-used package changes (e.g., when "base" changes). The current combination tries to hit a workable compromise between "the latest of everything" and "the latest that works for the current release". My guess is that the latest of a package will usually work with the latest release, mainly because package developers will be like other users and use the latest release. If so, things will generally work out. (In other words, I think that "misc1" is an exception in the way that it depends on a pre-release addition to "base", and I bet the author is willing to register a v6.1-compatible source.) If not, then we'll end up changing the policy at either "pkgs.racket-lang.org" or "pkg-build.racket-lang.org", or we may end up with multiple catalogs and multiple build services to support different modes. ____________________ Racket Users list: http://lists.racket-lang.org/users
