
The only place the Macaulay2 version number appears is in the file ./VERSION .

We have three main branches on github:

   development -- all pull requests are merged into this branch
   pre-master  -- development is manually merged into this branch occasionally, triggering builds
   master      -- pre-master is manually merged into this branch after builds succeed there.  Daily builds occcur here.

The development branch will always be ahead of the pre-master branch, and the pre-master branch will always be ahead of
the master branch, so the merges above are all done by fast-fowarding.

Near release time we have a release branch, with name of the form release-X.Y-branch, which is occasionally merged into development.

The convention for version numbers of Macaulay2 is this:
  1.18     : a major release, such as occurs every 6 months (May 15 and November 15), stable, made into binary distributions
  1.18.1   : a minor update, with changes people might want, stable, suitable
     	     minor updates to binary distributions on certain architectures
  1.18.1.1 : a development version, with no binary distributions

Here is the procedure:

    Things to do when incrementing the version number to X.Y.Z, say :
	 - increment the version number in the file ./VERSION
	 - add an entry to distributions/deb/changelog
	 - commit the two files and push upstream

    Things to do when developing a binary release for version X.Y (or version X.Y.Z)
       - on the development branch:
	 - increment version to X.Y, as described above.  Commit and push.
       - on the release branch:
	 - make a git branch of the form release-X.Y and switch to it
	      git checkout -b release-X.Y-branch
	 - push it upstream:
	      git push -u origin release-X.Y-branch
	 - update the file M2/Macaulay2/packages/Macaulay2Doc/changes.m2 to take
	      the release into account: check JSAG for published packages that
	      need certification (download the published version and add it, if
	      necessary, to the git repository tree so it can be linked to by
	      the certification data added now to the package; also add an
	      entry to changes.m2; for packages that are not already in the
	      repository, add them also to the file =distributed-packages);
	      find out what the new packages are since the previous release and
	      add entries for them.  Commit and push.
	 - prepare binary releases on the release-X.Y branch, committing minor
	      changes needed for building on various architectures.  Periodically
	      merge the branch into the development branch.  Continue accepting pull
	      requests into the development branch.
	 - when all the builds are complete, then
	      git tag release-X.Y
	      git push origin release-X.Y
	   This ensures that changes needed for building on various
	      architectures are available downstream
	 - using the common *.deb file on the web site, update the documentation and
	   version number there
       - on the development branch:
	 - merge the new release branch into development
	      git checkout development
	      git merge release-X.Y
	 - update version to X.Y.0.1 on the development branch, as described above

Note:
  Debian distributions may append a "downstream" debian release number N to the version number: X.Y.Z-N
  See distributions/deb/Makefile.in, where we allow for that, as a way to fix badly prepared binary distributions.
