The release process for v8.5 will begin in about a week. If you
have any new features that you want in and are relatively close to
to being done, now is a good time to do that.
Upcoming dates:
- 7th: Branch day, merge window starts
- 15th: Merge window ends, testing starts
- 22nd: Testing ends
The release process for v8.5 has begun: release checkpoints have
been created for all packages in the main distribution, and release
branches have been created when necessary. You can go on using
`master` branches as usual. The main Racket repo's is now bumped to
v8.5.0.1 (to avoid having two different trees with the same version).
If you have any bug-fixes and changes (including history updates)
that need to go in the release then make sure to specify that in the
commit message by using the word `merge` or `release` or mail the
relevant repo manager [1]) the commit SHA1s. Do not push commits
directly to `release` branches.
Please make sure that code that you're responsible for is as stable
as possible, and let me know if there is any new work that should
not be included in this release.
>>> NOW IS THE TIME TO FIX BUGS THAT YOU KNOW ABOUT <<<
The time between now and the end of the merge window is for fixing
new errors that prevent proper functioning of major components and
that show up during the preparation for a release. You can also
finalize piece of work that is not yet complete, but please avoid
merging new features.
Note that nightly builds will go on as usual (starting from
v8.5.0.1 and going up as usual), and pre-release builds will be
available shortly at
https://pre-release.racket-lang.org/
Please tell me if you think that this release is significant enough
that it should be announced on the users list for wider testing.
[1] https://github.com/racket/racket/wiki/release-repo-managers
Upcoming dates:
- 15th: Merge window ends, testing starts
- 22nd: Testing ends
While trying to build a pre-release, I noticed that most Git repositories for packages in the main distribution do not have release
branches (not even stale ones). It isn't a big problem, but it would be convenient to be able to find the commits that are going to be in the release (before the release is finished and the commits are tagged e.g. v8.5
).
These are the repositories that don't seem to have release
branches:
- https://github.com/racket/2d
- https://github.com/racket/algol60
- https://github.com/racket/cext-lib
- https://github.com/racket/class-iop
- https://github.com/racket/compatibility
- https://github.com/racket/contract-profile
- https://github.com/racket/data
- https://github.com/racket/datalog
- https://github.com/racket/db
- https://github.com/racket/deinprogramm
- https://github.com/racket/distributed-places
- https://github.com/racket/draw
- https://github.com/racket/ds-store
- https://github.com/racket/eli-tester
- https://github.com/racket/eopl
- https://github.com/racket/errortrace
- https://github.com/racket/expeditor
- https://github.com/racket/frtime
- https://github.com/racket/future-visualizer
- https://github.com/racket/games
- https://github.com/racket/gui
- https://github.com/racket/gui-pkg-manager
- https://github.com/racket/htdp
- https://github.com/racket/html
- https://github.com/racket/icons
- https://github.com/racket/images
- https://github.com/racket/lazy
- https://github.com/racket/macro-debugger
- https://github.com/racket/main-distribution
- https://github.com/racket/make
- https://github.com/racket/math
- https://github.com/racket/mysterx
- https://github.com/racket/mzcom
- https://github.com/racket/mzscheme
- https://github.com/RenaissanceBug/racket-cookies
- https://github.com/stamourv/optimization-coach
- https://github.com/racket/option-contract
- https://github.com/racket/parser-tools
- https://github.com/racket/pconvert
- https://github.com/racket/pict
- https://github.com/racket/pict-snip
- https://github.com/racket/picturing-programs
- https://github.com/racket/plai
- https://github.com/racket/planet
- https://github.com/racket/plot
- https://github.com/racket/preprocessor
- https://github.com/racket/profile
- https://github.com/Metaxal/quickscript
- https://github.com/racket/r5rs
- https://github.com/racket/r6rs
- https://github.com/jeapostrophe/racket-cheat
- https://github.com/racket/racklog
- https://github.com/racket/rackunit
- https://github.com/racket/readline
- https://github.com/racket/realm
- https://github.com/racket/redex
- https://github.com/racket/sasl
- https://github.com/racket/scheme-lib
- https://github.com/racket/scribble
- https://github.com/racket/serialize-cstruct-lib
- https://github.com/racket/sgl
- https://github.com/racket/shell-completion
- https://github.com/racket/simple-tree-text-markup
- https://github.com/racket/slatex
- https://github.com/racket/slideshow
- https://github.com/racket/snip
- https://github.com/racket/typed-racket
- https://github.com/racket/srfi
- https://github.com/racket/string-constants
- https://github.com/racket/swindle
- https://github.com/racket/syntax-color
- https://github.com/racket/trace
- https://github.com/racket/unix-socket
- https://github.com/racket/web-server
- https://github.com/racket/wxme
- https://github.com/racket/xrepl
Release branches are created by need. See the release process overview for more details, including a command you can use to get the commit that the release build uses for a particular package:
raco pkg catalog-show --catalog https://raw.github.com/racket/release-catalog/master/release-catalog/ <pkg-name>
For scripting, you should use the release catalog (URL above). For interactive purposes (eg, "will this bug fix be in the release?") you can use the release repo status page.
Oh, this is great! Somehow I hadn't noticed that wiki page before.
Also possibly relevant: the pre-release candidates are all available, at
https://pre-release.racket-lang.org/
I see that this URL doesn't occur in either of the messages that appear above ... but maybe that's appropriate, because it isn't usually until the 15th that anyone other than the package managers is expected to be running these.
Not sure. What do y'all think?
Publicizing that link seems good to me (not entirely sure I am following the context of the question precisely tho!)
Testing for the v8.5 release
(using the v8.4.900 release candidate build)
Search for your name on the checklist page to find relevant items, either
reply when you finish an item (please indicate which item/s is/are done),
or check it off yourself on the checklist page. Also, if you have any
commits that should have been picked, make sure that the changes are in.
Be sure to finish your testing by the 22nd. Otherwise the release
will move on without your input.
The checklist page is at:
https://github.com/racket/racket/wiki/Release-Checklist-8.5
Release candidates are at:
https://pre-release.racket-lang.org
Please use these installers (or source bundles) -- don't test from
your own git clone (don't test the `master' branch by mistake!).
To get the tests, you can do this:
cd ...racket-root...
./bin/raco pkg install -i --auto main-distribution-test
Here's a draft of the 8.5 release notes, let me know about additional items that should appear, items that are misleading or wrong, or things that are here but shouldn't appear:
-
Racket includes a new flag that automatically stores a compiled
version of the code being run. -
Error-message Realms allow languages to adapt and rewrite error
messages to make sense in a particular context. -
Nonprivileged users can control package installation scope using an
"other-version" directory in the addon-dir. -
Users of platforms without a native back-end can run Racket programs
at acceptable speed using the improved pb implementation. -
DrRacket's new 'Reopen Closed Tab' file menu item will open previously
closed tabs. -
Typed Racket has support for the
xml
library; usetyped/xml
. -
Rackunit reports source locations for failed test cases in the
Typed Racket language. -
Plot has violin plots and improved box-and-whisker plots.
-
The release includes many other repairs and changes!
My edit was very modest and and I’d be happy to leave it as one of the “many other repairs and changes”, but in case it’s of interest, a potential note could be:
- Boxes are now supported alongside lists, vectors etc. in place-channel messages
Best,
Tim
Sounds good. Can you rewrite this without using the word "now" ?
Does this change the recommendation from cs: build failure on debian ppc64el · Issue #3773 · racket/racket · GitHub that distribution packagers should use BC for platforms that CS does not support?
I don't think I have all the context to propose a revised bullet, but I think of the (non)existence of a "native back-end" as a property of a Racket VM implementation, and I'm also not sure that "pb" is a term we should expect release-note readers to know.
Should this perhaps say "Racket's new --<thing> flag causes racket to automatically keep compiled files up to date, improving load times while developing code" or something like that?
How about
- Racket's new
-y
flag automatically keeps compiled files up to date,
reducing load times dramatically.
?
- although if the plan is to avoid references to time, perhaps “new” should be trimmed too?
I agree with @robby that the flag should be mentioned. Since racket --help
lists quite a few flags, it might otherwise require some time to find out what the new option actually is called.
What are error message realms? A search in the Racket documentation and a general web search didn't find anything related (for realm and racket error message realm, respectively).
If this feature is only indented for language authors and you assume that they know what a realm is in this context, it's kind of ok for me, but it would be even better to use a term that can be looked up more easily.
Re realm: since it’s a new addition, you won’t be able to look it up from the documentation yet. But it will be there once 8.5 is released. Meanwhile, you can take a look at the documentation of snapshot release: https://plt.cs.northwestern.edu/pkg-build/doc/reference/exns.html#%28tech._realm%29
Maybe avoid "dramatically" (as it isn't always dramatic; especially if you have only one file that is changing)
Also there is the potential for significant compile time up front.
I agree that this entry needs to be explained more, and to point to the relevant documentation for using it.