Releasing - NetLogo/NetLogo GitHub Wiki

Here's how to build NetLogo release bundles.

Some of this information is usable by anyone. Some of it only applies to developers at Northwestern doing official CCL-sanctioned releases.

As you work through these instructions, look for things which could be more fully automated — and automate them!

The release build process is currently split into three steps:

1. A full build of NetLogo and various components which can be done on any machine
2. OS-specific packager generation which must be done on the target OS
3. The NetLogo page generator and uploader, which can be done on any OS

• jpackage: included with the JDK.
• wkhtmltopdf: must be in your path. Used to build the PDF version of the NetLogo manual. Installation information.
• python3 and numpy: must be in your path Needed for the python extension test.
• aspell : must be in your path. Needed for documentation spellchecking. On MacOS can brew install aspell in a terminal window if you have Homebrew.
• Mathematica installation (or a copy of the file JLink.jar in the directory /Applications/Mathematica.app/Contents/SystemFiles/Links/JLink.) Northwestern students, faculty and staff can obtain Mathematica version 12.0.0.0 by following the Installation information

The pre-2025/NL7 release system tried to do all sorts of "clever" sorcery, in a vain attempt to automatically find JDKs based on the operating system. For NetLogo 7, that was discarded and replaced with build-makers just explicitly stating the JDKs that they want to use for their build, as described in their .jdks.yaml file in the root of the repository.

The format of a JDK entry in the file will look something like this:

- vendor:       "OpenJDK"
  version:      "17.0.2"
  architecture: "64"
  path:         "/my/favorite/jdk-store/jdk-17.0.2/"

Valid values for architecture are "32", "64", and "universal".

• @ERSUCC says: "universal should never be used, and for mac it’s x86_64 and aarch64 rather than 32 and 64"

The path should be the value that you would otherwise use for a JAVA_HOME value, such that the expected executables are all present relative to path (e.g. bin/java, bin/javac, bin/jpackage (and with .exe at the ends of the names of those executables, on Windows)).

Once your JDK has been entered into .jdks.yaml, you just need to run a few commands.

• nativeLibs will acquire the requisite JOGL libraries
• dist/buildNetLogo will do the actual build
• dist/package<platform>Aggregate <jdk> will bundle up the relevant files for distributing to the public, and drop them into dist/target/downloadPages
  • <platform> will be Win, Mac, or Linux depending on which platform you're building for at the moment (likely constrained by which operating system is running on the machine that you're running this command on)
  • <jdk> is the name of a JDK, as computed from the information describing it in .jdks.yaml
    • For example, the JDK described in the example above would go by the name OpenJDK_17.0.2_64
    • You can simply press Tab to get a list of valid options, as pulled from .jdks.yaml

The windows build has been tested on Windows 10 and 11, but will probably work on other Windows platforms as well. To run the Windows packaging task, you will need to install the WiX toolset. The build has been tested to use WiX 5.0.2, but will probably work with any 5.x or 4.x version. It will no longer work with any 3.x versions due to lack of backwards compatibility between version 3 and version 4. You will also need the JDK appropriate for the architecture and version of java for which you plan to build. The command you use will look something like dist/packageWinAggregate OpenJDK_17.0.2_64. When building a release, you should build both 32 and 64-bit packages.

You will need an Apple ID account which is represented below as [email protected].

You will need the XCode command line tools for codesigning and notarization.

The .dmg-building stuff is Mac-only, so you must be on Mac OS X 10.10+. In order to sign the applications to get past Gatekeeper or into the App Store, you'll also need the proper signing certificates. If you can't find anyone who has the certificates you need, get in touch with Rodolfo Vieira or Harlan Wallach at NUAMPS (hint: the certificate you get must be a "Developer ID Application" certificate in order to work). You will also need your Apple developer account added to the Northwestern University organization in order to submit the package for notarization.

Details on installing the proper signing certificates. Copy their folder (Currently “MacOS-keys-2023-09-28”) to your hard drive. Open the app Keychain Access. In the upper left corner of the App Window under Keychains select login. Unlock the item if necessary. From File Menu select Import Items… Use the Chooser to select one of the files and enter the required password (available from dev-core). Repeat for the second file. These files are currently “MacOs - Application ID.p12” and “MacOS - Installer.p12”

The command you use will look something like dist/packageMacAggregate OpenJDK_17.0.2_64. Starting in NetLogo 7, we are producing one Mac Intel build (for machines that cannot run a Silicon build) and one Mac Silicon build (which shows much better performance on Silicon machines than Intel/universal builds have). An Intel-based machine must be used for the Intel build, and a Silicon-based machine must be used for the Silicon build.

The Linux build no longer uses the digital pox that is update-alternatives.

Your command will look something like dist/packageLinuxAggregate OpenJDK_17.0.2_64. You need to produce both 32-bit and 64-bit builds, and that can be done using a single machine, but requires using a 32-bit and a 64-bit JDK, respectively. OpenJDK is cool, but they don't provide 32-bit JDKs anymore, so you have to get your 32-bit JDK from elsewhere (e.g. Liberica).

You won't be able to run a 32-bit executable on a 64-bit Linux operating system. So one quick test that your build was a success is to try to launch the 32-bit NetLogo executable. If it actually launches, you messed up. Additionally, you should extract each build and run stat lib/runtime/lib/libawt.so on its contents. For a 32-bit build, the output will look something like:

ELF 32-bit LSB shared object, Intel 80386 [...]

On a 64-bit build, the output will be more like:

ELF 64-bit LSB shared object, x86-64 [...]

This is a quick way to verify that the builds are for the architectures that they claim to be. The best way, however, is to run them.

The current setup assumes that the entire build lives in one directory. This is actually quite tricky when you consider that there are three operating systems the build must run under. It isn't a problem to build under just one OS, but if you would like to build for all three at once, the easiest approach is to use virtual machines with shared/networked folders. Robert uses Virtualbox with Windows 10 and Ubuntu running on a Mac OS X host as a build platform. Similar approaches are recommended if you don't have three computers laying around. As of 2017, Robert recommend using NFS to share files between Mac OS and Linux as it's much faster than Virtualbox shared folders.

Aaron (2023) has run into issues using VirtualBox shared folders from a MacOS host to Linux and Windows guest machines. Specifically there was a failure at the packaging step. He uses the shared folders to copy the NetLogo directory and then builds and packages on the guest machines and copies the .msi and .tgz files back to the host.

See the releasing Linux VM setup page for more info on configuring shared folders and the JDK on a Linux VM for NetLogo packaging purposes.

If this is for public release, construct the base release notes from GitHub Issues / Pull Requests. If you like, you may be able to use the bin/issues.scala script. We maintain a private release notes repository with a wiki page maintaining historical release notes. Copy one of those and add bullets to get a draft of the release announcement that will be negotiated with Uri.

Note: Leveraging bin/issues.scala depends on having issues that are complete and accurate. Developers are very strongly encouraged to make a ticket for every bullet-worthy change, associated with the right milestone, so this method of writing release bullets will work.

Then, add any changes to the Models Library. You can probably get the Model Czar to supply you with this information.

Also add the release notes to docs/versions.md. For a long time, we only listed the most significant changes, since roughly 6.0 we've listed all changes. Prior to 6.0, we listed all the gory details in the wiki, since then we've just included them in the User Manual.

Decide if you need to upgrade the bundled Java. Consult https://www.oracle.com/java/technologies/javase/17u-relnotes.html for details on Java 17 updates. Upgrades should be UI-tested on all platforms. A Java release may introduce new UI bugs (this has happened on Mac) or it may remove previously buggy behavior that had been worked around. You may also find it helpful to look through differences in the openjdk and javafx mercurial repositories as the Java release notes have not always included all changes in the repositories. Currently (2023) we get Java JDKs for almost all platforms from /Library/Java/JavaVirtualMachines/liberica-jdk-17-full.jdk/Contents/Home with the exception of 32-bit Linux plus Java FX, which is available at https://www.azul.com/downloads/?package=jdk#zulu. Be sure to download the Full JDK, which may not be the default option. Java 17 is a an LTS (Long-Term-Support) release with Extended Support until September 2029. Java 21 is the most recent LTS release. Using it is dependent on updating some Java code that is no longer supported.

If it's upgrade time, ensure you install identical JDK versions across all build machines. On Linux and Windows you should install both 32-bit and 64-bit JDKs.

NetLogo desktop includes a standalone version of the NetLogo Web simulation page. This needs to be periodically re-updated to include the latest work on NetLogo Web. To update:

• Browse to http://www.netlogoweb.org/web, then click the HTML export button to get a static copy of the page.
• Rename and replace the existing net-logo-web.html file in the NetLogo repository
• Open the file, find the <script> element with id="nlogo-code".
• Delete and replace the empty model code that was inserted into the the element with a couple of special tags, like so: <script type="text/nlogo" id="nlogo-code" data-filename="<NetLogoModelName />"><NetLogoModel /></script>
• Test it out with File > Save As NetLogo Web... from the GUI.
• This step creates a lot of differences with the previous version, so you might want to make a separate commit for it.

This step can be skipped if it's not a real release.

To build all of the model previews—it takes a while!—run ./sbt netlogo/allPreviews.

Look carefully for any preview-generation attempt that might throw an exception—especially in a recently overhauled model. If you find yourself confused about a preview problem, see here.

If needed, update the version number and build date in the appropriate version.txt file. For any serious release, the date should be of format <month> <day of month>, <year> (i.e. Octember 42, 2525). For internal test releases, it's good to give the version name <version number>-RC<release candidate number> (i.e. 5.6.3-RC27). For non-serious builds, simply put INTERIM DEVEL BUILD as the date.

For any externally released builds, you will also want to update version numbers in build.sbt and project/Build.scala, as well setting isSnapshot to false. For major releases, you will also want to update Mathematica Link to reflect the version number of NetLogo being released.

Here is a sample version update commit for reference. Note that it sets the version snapshot values to false in build.sbt. This is for release purposes only, and the snapshot should be reset immediately after the build and package are complete.

If you plan to do a Windows build, UUIDs will be added for your version number on Windows. These are non-secret and should be checked into GitHub for builds that go out to more than a few users.

If needed, update the copyright year in shared/resources/system/about.txt. If the year changed, it's also an opportune time to make sure all source files have the GitHub link at the top. (This should be automated, but presently isn't.)

If needed, bump the version and release date in CITATION.cff.

For testing purposes, also update the default version number specified in the org.nlogo.core.Model class.

If you're updating a minor version (6.0 to 6.1), also consider these updates:

• If the major or minor version number has changed, update the transition guide URL (stored under key file.open.transitionGuide.url in GUI_Strings). Note this doesn't need to track the complete specific version number either.
• Consider updating the version compatibility tests in org.nlogo.api.VersionTests. Here is an example commit with minor version test changes. Potentially these tests could be completely automated to handle these minor (and major) version updates.

If you're updating a major version (6.1 to 7.0), also consider these updates:

• Check all deprecated API functions and remove them entirely. Make sure to document these removals in the appropriate wiki locations, like the Controlling API and the Extensions API.

Update docs/versions.md (and consider: if the release is on a branch, do other branches need to be updated as well?).

Update docs/requirements.md if system requirements have changed.

These are copied from previous release announcements with version numbers changed and release bullets replaced. A mild negotiation/approval process regarding this announcement will occur between Uri and the release manager.

For prereleases, don't forget to list all known issues (that is, known regressions) in every release announcement, even if we already mentioned them in the previous announcement; if stuff that people would ordinarily expect to work is broken, normally we remind them about it in every release.

Do a trial run of dist/buildNetLogo and as many platform-specific installers as you have time for, just to make sure something doesn't fail. This helps avoid nasty surprises later when you might be in a hurry.

Make sure any uncommitted changes have been committed and pushed (git status).

bundled-libraries.conf needs to be updated to list all bundled libraries and their latest version numbers.

If you are publishing a version of NetLogo with a new minor API version (e.g. moving from 6.1 to 6.2), ensure that the respective (e.g. 6.2) branch exists in the NetLogo/NetLogo-Libraries repository. If it doesn't, the Extension Manager will break. You must also update the libraries.conf file in that repository so that all of the downloadURL values point to files on the new branch. Note that this is the API version, not the NetLogo application version.

The location of the libraries.conf file is controlled by a config file on the CCL server that can be updated without a full re-release of the NetLogo desktop package.

As you work through these instructions, look for things which could be automated -- and automate them!

The double-asterisk (**) syntax used throughout requires zsh or bash >= 4.0. In bash it is an option. At the command line shopt globstar will tell you if it is on or off, shopt -s globstar will turn it on, and shopt -u globstar will turn it off.

• did ./sbt test pass? To rerun a single test that failed, replace <NameOfTest> with the actual test name
  ./sbt
  netlogo/testOnly *<NameOfTest>
  

  The names of the tests that failed can be found by searching backward in the .sbt output for FAILED, then looking back for the test name
  This is an excerpt from a failure of the test NetworkUtilsTest
  [info] NetworkUtilsTest:
  …
  [info] - findViableInterfaces does not return disabled interfaces *** FAILED ***
  

• add new team members if any to resources/system/about.txt

• think: are there any legal issues around the release? e.g. any new third party software? any updated third party software whose legal info might have changed? If you add something it goes in 3 places readme, about box, and copyright.html

• check that any classes that have serial version IDs have had those IDs changed if the classes have changed in ways that break serialization (note that you must check all superclasses as well).
  grep serialVersionUID **/src/**/*.java to find any values that are not 0L or 1L
  grep serialVersionUID **/src/**/*.java | grep -v " = [01]L"
• run bin/findbadsource.scala to find various problems with Scala and Java source files
• if you're really feeling ambitious, then in Eclipse, turn on more compiler warnings, then see if any of them catch stuff
• if any of the above checks failed & you fixed it, return to the top of the list and run them all again to make sure your fixes didn't cause new problems

• bin/spellcheckdocs.scala (make false positives go away by adding to dist/docwords.txt)
• generally make sure the docs are in sync with the software
• check the model count in tutorial1.html ("over 200 models"); also see if the list of sections in the Models Library has changed

• Have we regressed on speed since the last release? (use "./bin/benches.scala" to check by running overnight) [currently fails]
• Does everything work? even extras like shapes editor, BehaviorSpace, system dynamics modeler, 3D, sound...
• build the jars (use sbt package)

• newer JOGL, asm, PicoContainer, others? Note that JOGL has special update steps.

NetLogo does some magic to show you which versions of the JDK can be used to bundle Java on the system. The commands dist/packageWindowsAggregate and dist/packageLinuxAggregate try to be smart in showing you the options you can use with autocomplete, and will fail with any non-standard options.

This info could be out of date! Check the JavaPackager.scala file for the latest. If that file doesn't exist, then this info is definitely out of date.

Windows: Searches through the Program Files directories (regular and (x86) flavors) looking for a folder called Java, then for the jdk folder inside (to indicate it's a JDK not a JRE), then it looks for jpackage.exe, which it needs to do the packaging. Any folder inside Java meeting those requirements is listed.

Linux: Runs update-alternatives --list jpackage, searches for anything with jdk in the path, then filters based on the containing folder name having a single - character followed by 32 or 64. So bellsoft-java17-full-amd64 or zulu-fx-17-i386 would work.

MacOS: Just uses whichever version of jpackage is on the path. Usually this would be the same as whatever sbt picks up to use on startup, but always double-check.

These are the steps to actually get the full build complete and the installer packages generated and uploaded to the CCL website for a wider release (beta or final).

Did you update bundled-libraries.conf with any extension version changes?

You may want to do a fresh checkout instead of using an old one (or use git clean -xdf and git submodule foreach git clean -fdx and make sure your git status is totally clean). Use git log to make sure any recent changes you made are there.

• Open ./sbt on your macOS system.
  • dist/buildNetLogo.
  • dist/packageMacAggregate.
• Notarize the macOS package (see full steps below). You cannot distribute the macOS package without notarizing or users will get errors.
  • You can submit the macOS package for notarization and continue building the other packages in parallel.
• Exit sbt on macOS, open the Windows virtual machine. Run sbt in the same directory you ran your macOS commands.
  • ; dist/packageWinAggregate <java-version>-32 ; dist/packageWinAggregate <java-version>-64
  • Once the packages are made, it is a good idea to immediately smoke-test them, installing on the system and running through basic testing (see the Release Testing page).
• Exit sbt on Windows, shut down the Windows virtual machine, and open the Linux virtual machine. Run ./sbt again in the same directory you ran your macOS commands.
  • ; dist/packageLinuxAggregate <java-version>-32 ; dist/packageLinuxAggregate <java-version>-64
  • Once the packages are made, it is a good idea to immediately smoke-test them, installing on the system and running through basic testing (see the Release Testing page).
• Exit sbt on Linux, shut down the Linux virtual machine, and return to the macOS system.

Where <java-version> is something like java17, depending on which JDK you are targeting. The sbt console will auto-tab-complete those version numbers so you can see what's available. If you don't see the version you want, you have to tweak your config settings for the OS.

• Check-in the generated windows .properties file. See this commit for an example.
• The version numbers of all models will be updated during the final build and packaging, so we'll nee to check-in those modifications for future reference.
  • Just add all the changed models and commit them on a separate branch from the models library's master branch.
  • Tag the branch with a name matching the release and then push the branch and tags up.
  • You can then delete the branch from the models library repository, since this release is just for posterity, we don't ever merge it back to master.
• Open ./sbt again on your macOS system.
  • dist/generateLocalWebsite
  • dist/buildDownloadPages
  • dist/uploadWebsite
• Check permissions on the server (they are usually wrong)
  • ssh ccl.northwestern.edu chmod -R go+rX /usr/local/www/netlogo/<version>
  • ssh ccl.northwestern.edu chgrp -R apache /usr/local/www/netlogo/<version>

At this point you have built, packaged, and deployed a release. If you're doing a beta or release candidate, this might be all you need to do, other than tagging the release in the NetLogo repository and maybe publishing artifacts to Cloudsmith. If you're doing a final release, you have more work in the releasing section below.

There is a new macOS notarization process as of November 2023. If you are familiar with the previous process you may find this helpful.

The process requires the notarytool, which is available in recent versions of XCode. If you run xcrun notarytool at a terminal prompt and documentation is printed out, notarytool is installed.

xcrun notarytool  -u [email protected] --team-id E74ZKF37E6 --password <ApplicationSpecificPassword>

The above command will submit the generated macOS package for notarization to apple. The password prompts for all of these are the "app-specific password for your Apple ID" , which you'll need to have generated (see Apple's documentation for more). The team-id comes from the signing certificates and is Northwestern specific.

This can take a while to complete since the package is around 215 megabytes, so I highly recommend the --verbose option to get some status updates.

When following the Apple instructions if your your Apple ID account page does not have the option APP-SPECIFIC PASSWORDS, it may be because you have not turned on two-factor authentication.

To avoid having to enter your for each xcrun command you can add it to password keychain as follows:

xcrun altool --store-password-in-keychain-item "AC_PASSWORD"  -u [email protected] -p <ApplicationSpecificPassword>

Then for many xcrun commands you can add the option -p "@keychain:AC_PASSWORD" to include your password. However this can not be used with notarytool submit. For that you need to create a keychain profile using the command

xcrun notarytool  -u [email protected] --team-id E74ZKF37E6 --password <ApplicationSpecificPassword>

or

xcrun notarytool  -u [email protected] --team-id E74ZKF37E6 --password "@keychain:AC_PASSWORD"

If this is successful you should get a message

Success. Credentials validated.

Credentials saved to Keychain.

To use them, specify --keychain-profile "[email protected]"

Steps for notarization using the keychain profile start here.

xcrun notarytool history --keychain-profile "[email protected]" ./dist/target/downloadPages/NetLogo-#.#.#.dmg  --verbose --wait
xcrun stapler staple ./dist/target/downloadPages/NetLogo-#.#.#.dmg

The --wait option will not return until notarization is complete (or fails). This approach ensures that the staple step is included. Without the --wait option the submit command will return right away and will return a <RequestUUID> you can use with other commands. You can use that ID to check on the progress with this command:

xcrun notarytool info --keychain-profile "[email protected]" <RequestUUID>

If you lose the <RequestUUID> you can get it through your history:

xcrun notarytool history

Once the notarization is complete, you should get an email alert. Otherwise, you'll see the status in the --notarization-info command output.

If you haven't already done it should can staple the disk image with the notarization.

xcrun stapler staple ./dist/target/downloadPages/NetLogo-#.#.#.dmg

Finally, you can validate the notarization of a disk image with this command. You should see something like NetLogo-#.#.#.dmg: accepted, source=Notarized Developer ID.

spctl -a -t open --context context:primary-signature -v /path/to/NetLogo-#.#.#.dmg

And to check an app:

spctl -a -vv /path/to/NetLogo\ #.#.#/NetLogo\ #.#.#.app

If notarization fails you can get specific failure information. The output of

xcrun notarytool info --keychain-profile "[email protected]" <RequestUUID>

Will include output with a line LogFileURL: <LogFileURL> where <LogFileURL> may be over 300 characters long. You can get this output by something like

wget -O your/path/notarization-log.json <LogFileURL>

This output will contain specific error messages such as "message": "The binary is not signed.", with associate "path": entries that locate the source of the error.

In theory the notarization submission could be automated, but many times when we generate macOS packages, we're not doing it for release. Also, if we put in the effort to automate submission, it'd be even better to automate stapling after notarizing. As noted above using the --wait option with notarytool submit makes it possible to 'automate' stapling.

Tag the release in git—even release candidates.

git tag <version> # don't prefix a `v`, just use the number
git push origin <root> --tags # root being your current branch

If you don't feel the release is ready to tag, send yourself an email reminder or something. It's super super easy to forget later. It's such a trivial thing to do, though, that you should probably just do it right away, and, if you mess up, just tag the next build as a new release candidate.

We do a full set of Release Testing manual "smoke tests" on each platform, as a final check that everything is working as expected and the build is worthwhile for users to download (even beta/testing builds).

For either testing releases or milestone releases, typically after upload to the CCL website, a direct link to the download page for the version is shared internally to the CCL to get extra smoke testing before the public download page is updated so anyone in the public can grab it.

Testing releases are added to the dropdown on the NetLogo download page, but not set as the default as milestone releases are. As such users have to know to look for them there to find them, as indicated by a release announcement.

The download.shtml file needs to be updated with the new version in the dropdown, and the download.cgi file needs to be updated with it as well, for tracking in our version tracker. These changes should be automatically pushed by GitHub Actions and can be tested before the release announcement is sent out.

Once the final release is done, these edits can be changed to the milestone version instead. Typically there is no need for a beta version to be referenced in either file.

A public release requires updating the NetLogo website with some links and HTML file changes so the latest documentation is presented, and the new version appears in the download options for users.

The folder setup on the NetLogo website uses a series of symbolic links to try to keep URL updates to a minimum. It kind-of works. For example, the docs link points to the latest minor version, so docs -> ./6.1/docs, but the minor version is just a symlink to the latest patch version, so really docs -> ./6.1/docs -> ./6.1.1/docs.

• Pull down the latest version of the netlogo-site repository.
• Create the placeholder dirs: mkdir 6.1.1; mkdir 6.1.1/docs; mkdir 6.1.1/models
• If you're doing a patch version update (6.1.0 to 6.1.1):
  • rm 6.1 # remove old minor-version symbolic link that was pointing to 6.1.0 -- check first
  • ln -s 6.1.1 6.1
• If you're doing a major or minor version update (say, 6.1 to 6.2):
  • rm docs; rm models/models
  • ln -s 6.2/docs docs; cd models; ln -s ../6.2/models models
• You can then search (via grep -R or git grep or your text editor's search) for files containing the old version you are replacing.
  • However, don't blindly delete occurrences of the previous version number; some (such as in oldversions.html) are to coexist with the new version number.
• Commit all your changes (including the symlink changes) and push them up to the server on a branch. Here is an example of some updates for a patch-version release. Here is an example of some updates for a minor version release.
• Once everything looks good, merge to master and push again (or merge via pull request)
• Once the GitHub Actions deploy of the netlogo-site is done (you can kick it off early if you're impatient), everything should be updated on the server.
• Browse the site and make sure the download links and documentation links are all correct.
• Make sure the Models Library and Community Models pages are correct.

There's probably a better way to do this stuff. If so, do it!

DID YOU TAG THE RELEASE YET?

Publish by using ./sbt ';parserJS/publish;parserJVM/publish;netlogo/publish;headless/publish'. Ensure that the tagged version is the version published. Releases after this point must be published under a different version number (I've used "-mk2" for that before, when a release has required last-minute fixes). If you publish before you meant to, Cloudsmith does let you delete the artifact.

DID YOU TAG THE RELEASE YET?

Check that the milestone is marked as closed on GitHub, by reassigning any remaining open tickets to a future milestone.

Update the NetLogo pages, including the download forms; be sure to actually grep for the old version number, because if you don't, you're almost certain to miss some. Also the what's new notice on the Models Library page. The NetLogo website is a git repository, so you can use git commands to see what changes took place when previous versions were released. You can also use git to undo mistakes.

Send the public release announcement to Uri for him to send out.

DID YOU TAG THE RELEASE YET?

Bump the version number again in version.txt and change the build date back to INTERIM DEVEL BUILD.

Maybe run benchmarks.

Maybe update architecture page, devel requirements page, and others in wiki.

If public, announce on the netlogo account on Twitter.

If Uri made changes to the release announcement when he sent it, see if any corresponding changes need be made at Release notes.

Update wikipedia with the latest version number and date.

DID YOU TAG THE RELEASE YET?