-
Notifications
You must be signed in to change notification settings - Fork 13
Making a New Release
This covers the process of making a new release.
First, run some checks locally (though it's not really necessary since CI will do these anyway).
make build-all
make check-deps
- Do you need to add version exceptions? Now is the right time to do that.
- Are there any custom release steps to go through for your PR, which may be captured in a pre-merge checklist?
- If there are backwards incompatibilities, announce a migration plan and also document it in the draft Release Notes.
- Ask concerned parties to test dependent packages to ensure they are still OK.
Bump the version in info.rkt
and make a fresh commit
(define version "i.j.k") ; numbers corresponding to major.minor.patch
Tag the release commit
$ git tag -n<NUM> # list existing tags and annotations; if specified, NUM configures verbosity
$ git tag -a <new version number> -m "<release message>" # or leave out -m to enter it in Vim
Push the changes including the new tag to origin
$ git push --follow-tags # push new tag to remote
In case of any issues following release, consult the Package Build Results page as it may contain more specific information.
After releasing the new version, keep an eye on the package server for around half an hour to see if there are any build failures or conflicts reported there. CI workflows can only test that the code is internally consistent and working correctly, but on the package server, there are also interactions with other packages in the global collection namespace.
If there are no issues, check again in about 24 hours to make sure, as that is the cadence of the full documentation refresh cycle.
Verify that the package docs are visible on the Racket Documentation Server.
Schedule a round of DIA to update the project attributions for Attribution Based Economics.
Home | Developer's Guide | Calendar | Events | Projects | Meeting Notes