The release process for v8.13 will begin in less than 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:
- 10th: Branch day, merge window starts
- 17th: Merge window ends, testing starts
- 23nd: Testing ends
The release process for v8.13 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.13.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.13.0.1 and going up as usual), and pre-release builds will be
available shortly at
https://pre-release.racket-lang.org/
[1] https://github.com/racket/racket/wiki/release-repo-managers
Upcoming dates:
- 18th: Merge window ends, testing starts
- 24th: Testing ends
(slipped another day, mea culpa)
Testing for the v8.13 release
(using the v8.12.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 30th. Otherwise the release
will move on without your input.
The checklist page is at:
https://github.com/racket/racket/wiki/Release-Checklist-8.13
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
The release announcement sketch that I have so far is below. Please
mail me new items and/or edits.
Please phrase announcements using complete sentences and avoid the
word "now".
-
The
racket/treelistandracket/mutable-treelistprovide implementations
of Bagwell, Riompf, Stucki, and Ureche's RRB Vectors for Racket. -
The
hash-filter-keysandhash-filter-valuesfunctions allow users
to filter hashes using a predicate on either keys or values. -
The
vector-extendandvector*-extendfunctions provide a way
to pre-populate the prefix of a newly allocated vector using the elements
of an existing vector. -
The
syntax-local-lift-require-top-level-formfunction allows syntax
transformers forrequireelements to produce top-level forms that are
inserted following the currently-being-expandedrequireform. -
The
syntax-local-make-definition-context-introducerfunction allows
syntax transformers to prune a single scope from a set of scopes during
expansion. If you don't know whether you need this function, you
probably don't need this function. -
Racket v8.13 uses Unicode 15.1 for character and string operations.
-
Machine-specific cross-module optimization allows improved support for
static generation of foreign-function bindings. -
The scribble/acmart language uses v2.01, which avoids errors
concerning the hyperref package in some latex installations.
The following people contributed to this release:
Alec Mills, Ben Greenman, Bob Burger, Bogdan Popa, dented42, Fred Fu,
Gustavo Massaccesi, Jason Hemann, Jay McCarthy, John Clements, Jordan
Johnson, Justin Dhillon, Mao Yifu, Matthew Flatt, Matthias Felleisen,
Mike Sperber, olopierpa, Oscar Waddell, Pavel Panchekha, Philip McGrath,
Robby Findler, Sam Phillips, Sam Tobin-Hochstadt, Siddhartha
Kasivajhula, Sorawee Porncharoenwase, Stephen De Gabrielle, Tim Standen,
William E. Byrd, Wing Hei Chan, and Δ̷̨̧̡̭̺̙̞͖̖͕̰̥̙̯͙̞̯̗̔͌͐̿͊̌́̄̑̿̓̉̈̀͘͠λ̶͔͓̘̘̳͇̻̍̏͌̅̓̓͂̍̾̔͜λ̶̛̯̖̯̲̱͎̙͎̎̐͆͂̽̓̇́͌́̀̏̎̅͋̏̊͘λ̶̨̨̰̟̯̫̲̲̫̯̭̤̳̼̫͉̹̞́̐̒Δ̷̡̛̥̖͇͚͍͍̄̏̂͛̅̌͗̂̽̅̀͆̿̔̚͜
Is there a better name that we should use for @dr-neptune on GitHub? Note that in the 8.9 release, we used the name dr-neptune.
Particularly, I don't think the name should "disrupt" nearby text.
Also, do we want to mention the progress bar "feature" in raco setup?
I'm happy to do whatever others want, here. I admit that I'm mildly amused by the disruption, but I suppose it could get old. I'm going to discount my own vote here and say that I'm going to regard your opinion as a vote against the disruption, making the current vote tally 1-0 in favor of renaming to dr-neptune. I would definitely like to hear from @dr-neptune here!
I would defer to @robby , I think he's the author? I could easily be wrong about this. I find it useful to be able to see which threads are idle, ... I would probably write something like this:
- Command-line compilation features a progress bar that shows a progress bar and a dynamically-updated indicator of what each build thread is working on.
Uh... "a progress bar that shows a progress bar". Yep, that's the kind of progress bar I'm talking about.
- Command-line compilation features both a progress bar and a dynamically-updated indicator of what each build thread is working on.
Ending my sentences with prepositions now, what would Dr. Graulich say about me now...?
Maybe it would be better to describe the functionality of treelists, something like:
- The
racket/treelistandracket/mutable-treelistlibraries provide list-like containers that support many operations in effectively constant time, including inserting, updating, or deleting elements at arbitrary positions and appending or extracting treelists.
(In any case, a noun like "libraries" is needed before "provide".)
I would mention contract-in in addition to, or maybe even instead of, this.
Is this worth including in the release note?
I am looking forward to this feature and agree it's worth mentioning here. If there's a concise way to describe how to turn it off, it might be worth mentioning that, too.
Tangentially, how did you render this screenshot? This is what it looks like for me in Firefox, and Chromium looks fairly similar:
(I agree with using dr-neptune or whatever @dr-neptune prefers, though.)
1 Like
Confirmed; I can see it that way by changing the font.
*eyes some half-finished code* 
Hey folks,
I also find the disruption mildly amusing. Happy to switch it to dr-neptune 
Oh! I know that feeling.
If I recall correctly, the same problem exists in gmail.
I think we should hold off on the contract-in announcement. The version that is in this release is fairly minimal one and the full-featured one (that matches what you can do with contract-out) was merged only after the release branch was created. So, if everyone is okay with it, it seems better to announce it for the next release.
In principle, @dr-neptune could fix this problem by choosing a name that's sufficiently long that the disruption applies only to characters in their own name. So, for instance, Δ̷̨̧̡̭̺̙̞͖̖͕̰̥̙̯͙̞̯̗̔͌͐̿͊̌́̄̑̿̓̉̈̀͘͠λ̶͔͓̘̘̳͇̻̍̏͌̅̓̓͂̍̾̔͜λ̶̛̯̖̯̲̱͎̙͎̎̐͆͂̽̓̇́͌́̀̏̎̅͋̏̊͘λ̶̨̨̰̟̯̫̲̲̫̯̭̤̳̼̫͉̹̞́̐̒Δ̷̡̛̥̖͇͚͍͍̄̏̂͛̅̌͗̂̽̅̀͆̿̔̚͜_______________
