mirror of
https://github.com/Mercury-Language/mercury.git
synced 2025-12-08 18:34:00 +00:00
9777cf86b5
Estimated hours taken: 2 Localize the definition of the version number into a single file. Automate the building of releases, including daily "rotd" (release-of-the-day) releases. VERSION: New file, defines the version number. Also document the general scheme for assigning version numbers. Mmake.common.in: Add `include VERSION'. Mmakefile: bindist/Mmakefile: configure.in: Use the version number in VERSION rather than hard-coding it in multiple places. Mmakefile: README: .README.in: INSTALL: .INSTALL.in: Change things so that README and INSTALL are automatically generated from .README.in and .INSTALL.in respectively, using the version number defined in VERSION. BUGS: Remove an unnecessary reference to the version number. RELEASE_NOTES: Change this file so that the version number is only mentioned in one place. Bump the version number here to 0.7 in preparation for the next release. library/Mmakefile: library/library.m: library/library.m.in: Change things so that library.m is automatically generated from library.m.in using the version number in VERSION. Also change it so that library__version says which architecture it was configured for. tools/test_mercury: Override the version specified in the VERSION file in the CVS repository with either `rotd-YYYY-MM-DD' or (when making a release) with a specified $RELEASE_VERSION. When running on murliboobo, if the version built passes all its tests, copy it to the /pub/mercury/beta-releases directory on ftp://turiel.cs.mu.oz.au. compiler/notes/release_checklist.m: Change the release checklist to say that you only need to update the version number in VERSION rather than in 6 different places. Also change the procedure for building the final tar file to reflect the above changes to the `test_mercury' script.
43 lines
1.5 KiB
Plaintext
43 lines
1.5 KiB
Plaintext
# This is the central place where the version number is kept.
|
|
# (But note that the version number for the last major release is
|
|
# hard-coded in the RELEASE_NOTES file.)
|
|
#
|
|
# The version number must be a valid file name, i.e. it should
|
|
# not contain whitespace or special characters. Stick to [A-Za-z0-9._-].
|
|
#
|
|
# Please assign version numbers according to the scheme explained below.
|
|
|
|
VERSION=DEV
|
|
|
|
# We use the following general scheme for version numbers:
|
|
#
|
|
# Pattern Examples Explanation
|
|
# ------- ------- -----------
|
|
# *.* 0.6, 0.7 Major releases.
|
|
#
|
|
# *.*.* 0.6.1 Bug-fix releases.
|
|
#
|
|
# rotd-<DATE> rotd-1997-07-28 "Release-of-the-day" releases.
|
|
# These releases are snapshots of our
|
|
# development sources built automatically
|
|
# after they have passed our nightly
|
|
# automatic test process.
|
|
#
|
|
# <BASE>-<PATCH> "Unofficial" releases (releases of patched
|
|
# 0.6.2-1 versions by anyone other than the Mercury
|
|
# team). BASE should be the official
|
|
# release on which it is based,
|
|
# e.g. "0.7", or "rotd-97-07-28".
|
|
# PATCH should be something uniquely
|
|
# identifying this release.
|
|
# (In the example "0.6.2-1", PATCH was "1",
|
|
# which is not a good choice. Something like
|
|
# "0.6.2-debian1" would have been a better name.)
|
|
#
|
|
# DEV DEV Generic version number used internally by
|
|
# the Mercury team for development versions.
|
|
#
|
|
# DEV-<NAME> DEV-blah Version numbers used internally by
|
|
# the Mercury team for specific development
|
|
# versions.
|