Release versioning

[Kevin E Martin]

While at DDC/OLS last week, we -- the three release managers -- came up
with a policy to handle release versioning.  We discussed it with other
developers at the conference or on IRC, and there was general agreement
on the plan.  Please see the versioning policy below.

If you have questions or suggestions on how to improve the macro, please
let us know.  We will be implementing this tomorrow night in preparation
for the initial release candidate.

Alan Coopersmith, Adam Jackson and Kevin E. Martin


Versioning in the modular source tree
-------------------------------------

Packages have two versions associated with them:

1. The package development version

This version is used to identify current version of the library,
application, etc. that the package maintainer and developers keep up to
date.  The format of these version numbers and rules for when to
increment them are set by the package maintainer.  This version number
is new in the modular source tree.

2. The X Window System release version

Packages in official X.Org releases need to be easily identified with
the release in which they were included.  To do this the release version
string (e.g., X11R7) will be included in the package name.  This is
consistent with past naming conventions from the monolithic tree where
the entire source tree was released as X11R6.8.2-src*.tar.gz, and it
preserves the widely-known and well-established X Window System brand.

Note that packages released that are not part of an official X.Org
release do not need and will not include the X Window System release
version string.

For example, libXrender is currently at version 0.9.0 in the modular
tree and if there are no further changes in the package before the next
X.Org release (i.e., X11R7), then the official package tarball would be
named:

    libXrender-X11R7-0.9.0.tar.gz

Then, if patches are made to libXrender after the X11R7 release and the
development version is bumped up to 0.9.3, then the package maintainer
could decide to make an intermediate release that is not part of an
official X.Org release, and the tarball would be named:

    libXrender-0.9.3.tar.gz

In addition, the mechanism to add the X.Org release version string to
the package tarball name is generic and can be used by other individual
developers to distribute special releases for others to test/use.  For
example, if the libXrender maintainer would like to release a test
version, he could name it:

    libXrender-testing-0.9.9.tar.gz

However, we request that all special versions use lower-case names as we
would like to reserve upper case names for official releases.

This naming scheme will allow independent development of packages with
releases between official X.Org roll-up releases, clear associations
with officially released packages, and continues the well-established X
branding on releases.


To enable this versioning system, we will require that all packages
included in the modular source tree add one line to their configure.ac
files:

XORG_RELEASE_VERSION

This macro will be defined in xorgversion.m4, which will be stored in
the macros component of the util module.  Here is the macro definition:

AC_DEFUN([XORG_RELEASE_VERSION],[
	AC_ARG_WITH(release-version,
			AC_HELP_STRING([--with-release-version=STRING]
				[Use release version string in package name]),
			[RELEASE_VERSION="$withval"],
			[RELEASE_VERSION=""])
	if test "x$RELEASE_VERSION" != "x"; then
		PACKAGE="$PACKAGE-$RELEASE_VERSION"
		PACKAGE_TARNAME="$PACKAGE_TARNAME-$RELEASE_VERSION"
		AC_MSG_NOTICE([Building with package name set to $PACKAGE])
	fi
])