common-lisp/roswell.roswell
1
0
Fork 0
mirror of https://github.com/roswell/roswell.git synced 2026-09-10 07:16:17 -04:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity
Page: Release Roswell
Pages
1. Installation Advanced scripting Basic Usage Building images and executables Circle CI Coveralls FAQ GitHub Actions Home How is Roswell different How to distribute your software, not library, on Quicklisp ala python pip How to setup a lisp dev environment on windows with Roswell Initial Recommended Setup Installation List of Roswell Installable Scripts Listing various resources Local installation Policy on how Roswell affects or manipulates your system Practical Usecases Reducing Startup Time Release Roswell Roswell as a Scripting Environment Roswell as a Testing Environment Roswell as an implementation manager Roswell in Virtual Environments Set up guide for Anaconda virtual env Support New implementation Travis CI Upgrading Roswell ros template
4 Release Roswell
SANO,Masatoshi edited this page 2026-02-24 08:06:32 +09:00
Table of Contents

Roswell Release Procedure

Prerequisites

  • master branch is up to date
  • ros is available (cl-ppcre, split-sequence, local-time are required)
  • git user.name and user.email are configured
  • automake is installed (otherwise make targets may fail after configure.ac is modified)

Overview

A release consists of 7 steps. Each step corresponds to a Makefile.am target or a manual git operation.

1. Prepare ChangeLog       make release-changelog
2. Edit ChangeLog          (manual)
3. Update version          make release-prepare
4. Commit                  make release-commit
5. Tag                     make release-push
6. Push                    (manual)
7. Update CI version       make release-ci + push

Step 1: Prepare ChangeLog entry

make release-changelog

What happens:

  • Checks out master
  • Prepends a new entry template to ChangeLog with a placeholder version master-changelog-which-not-yet-released
  • Automatically runs git add ChangeLog and git commit

Step 2: Edit ChangeLog (manual)

Open ChangeLog and describe the release contents in the * lines:

roswell (master-changelog-which-not-yet-released-1) unstable; urgency=low

  * Fix: ros fmt rewritten to use cl-indentify instead of Lem
  * Change: macOS CI runner updated to macos-15-intel

 -- ...

No need to commit after editing; the next step handles it.

Step 3: Update version number

make release-prepare

What happens:

  • Displays the current version (read from configure.ac)
  • Prompts for a new version number (default: auto-generated in YY.MM.N+1 format)
  • Press Enter to accept the default, or type a custom version
  • Updates the following files:
    • ChangeLog — replaces placeholder version, updates signature timestamp
    • configure.ac — AC_INIT version
    • roswell.asd — :version
  • Does NOT commit — that is the next step

Step 4: Release commit

make release-commit

What happens:

  • Runs git add ChangeLog configure.ac roswell.asd
  • Commits with message "bump version to X.Y.Z"

Step 5: Create tag

make release-push

What happens:

  • Creates an annotated tag v{version}
  • Does NOT push. You must manually run:
git push --tags
git push origin master:master

Pushing the tag triggers platform CI builds (linux.yml, osx.yml, windows.yml) which build and upload release artifacts.

Step 6: Wait for CI builds

Important: Wait for the tag-triggered CI builds (linux.yml, osx.yml, windows.yml) to complete successfully before proceeding. The next step updates the release branch, and test.yml downloads release artifacts — if they don't exist yet, tests will fail.

Check CI status:

gh run list --limit 10

Step 7: Update CI test version

make release-ci

What happens:

  • Updates ROSWELL_RELEASE_VERSION in scripts/install-for-ci.sh to the new version
  • Commits on master
  • Merges master into the release branch
  • Does NOT push. You must manually run:
git push origin master:master
git push origin release:release

This ensures test.yml (daily cron) uses the new release for testing.

Quick Reference

# 1. Create ChangeLog template
make release-changelog

# 2. Edit ChangeLog (manual)

# 3. Update version (interactive prompt)
make release-prepare

# 4. Commit
make release-commit

# 5. Create tag
make release-push

# 6. Push tag and master
git push --tags
git push origin master:master

# 7. Wait for CI builds to complete (linux, osx, windows)
gh run list --limit 10

# 8. Update CI and release branch
make release-ci
git push origin master:master
git push origin release:release

Version Numbering

Versions follow the YY.MM.N format:

  • YY — last two digits of the year
  • MM — month
  • N — sequential number (auto-incremented by +1)

The inc-version function in scripts/release.ros auto-generates this based on the current date.

Files Modified During Release

File What changes
ChangeLog New entry added, version and signature updated
configure.ac Version in AC_INIT
roswell.asd :version
scripts/install-for-ci.sh ROSWELL_RELEASE_VERSION (Step 7 only)

Notes

  • Step 1 (release-changelog) must be run before Step 3 (release-prepare). If no placeholder entry exists in ChangeLog, release-prepare will fail.
  • If make targets fail with aclocal errors after Step 3, run ./bootstrap first to regenerate autotools files, or invoke ros scripts/release.ros <subcommand> directly.
  • release-ci (Step 7) includes a merge into the release branch. It is safest to run this after the tag push and CI builds have completed.
  • On macOS, test.yml installs roswell via Homebrew. After a new release, it may take some time for the Homebrew formula to be updated automatically.

Home

Getting started / Tutorials

Advanced Installation

Roswell as a scripting environment

Roswell as an implementation manager

Roswell as a Testing Environment

Distributing applications

FAQ

For Developers/Maintainers