mirror of
git://git.code.sf.net/p/sbcl/sbcl
synced 2026-09-10 07:26:40 -04:00
This updates the SBCL build and release process to be more compatible
with distributed development -- to facilitate moving the upstream
repository into Git.
A detailed description of what is going on here is in
doc/GIT-WORKFLOW.md.
Some highlights:
* Drop version.lisp-expr and branch-version.lisp-expr.
* Auto-generate the version at build time using information
from Git, incorporating:
- Last release number.
- Number of commits on origin/master since last release.
- Current branch, if there are commits not on origin/master.
- Number of commits not on origin/master.
- SHA1 id of the last commit.
- Optional -dirty marker.
* Update release.sh to work with Git.
* Make source-distribution.sh exclude the .git directory from tarballs.
* Release tags contain NEWS for that release.
25 lines
788 B
Plaintext
25 lines
788 B
Plaintext
Packaging SBCL
|
|
==============
|
|
|
|
If you package SBCL for distribution, we ask that you to take steps to
|
|
make the version number reflect this. Our users often report bugs that
|
|
are intimately tied up with configuration issues, and much confusion
|
|
can result from mistaking a packaged SBCL for the upstream one.
|
|
|
|
If you are working from a Git branch, all you need to do is make sure
|
|
the branch name reflects the situation -- the build system will
|
|
incorporate the it in the version string.
|
|
|
|
If you are working from a release tarball, please edit
|
|
version.lisp-expr, and append ".packaging-target-or-patch[.version]".
|
|
|
|
Examples:
|
|
|
|
"1.0.50.gentoo"
|
|
"1.0.50.mikes-rpms.2"
|
|
|
|
This will make the startup banner, --version, and
|
|
(lisp-implementation-version) all identify the packaged version
|
|
correctly.
|
|
|