this is my proposal for release procedure - it's quite simple and covers all the technical details you need to know regarding autotools.
Changelog: - re-diff with current master (and not my internal branch :) - renumber the steps Signed-off-by: Jan Safranek <[email protected]> --- README | 17 ----------------- doc/internal/release.txt | 32 ++++++++++++++++++++++++++++++++ 2 files changed, 32 insertions(+), 17 deletions(-) create mode 100644 doc/internal/release.txt diff --git a/README b/README index 93e0aae..54e0f7b 100644 --- a/README +++ b/README @@ -1,20 +1,3 @@ -Please follow the following steps (TODO: Automate these steps) - -0. Update package version in AC_INIT (configure.in) -1. Tag the current sources in trunk to the specified version -1. Run autoreconf -i to generate the configure file again - (on changing any of the automake files) -2. Run configure with --prefix=<desired prefix> default is /usr/local -3. This step should generate - a. Makefile - b. libcgroup.spec -4. To build the RPM, carry out the following steps (obsolete, will be revised) - a. Create a tag with the same version as specified in step 0 - a. Run mktarball - b. copy tarball and spec file to correct place in the RPMBUILD - c. Build an rpm of the spec file - - Design ======== diff --git a/doc/internal/release.txt b/doc/internal/release.txt new file mode 100644 index 0000000..e356cef --- /dev/null +++ b/doc/internal/release.txt @@ -0,0 +1,32 @@ +Libcgroup release procedure +=========================== +Please follow the following steps (TODO: Automate these steps) +1. Check, that every new or changed feature since last release is reflected in + README and/or man pages. +2. Bump soname of libcgroup shared objects if needed - LIBRARY_VERSION_MAJOR, + _MINOR and _RELEASE in configure.in. +3. Prepare release candidate (X.YY-rcZ - X.YY = version, Z - prerelease +umber): + a. Update AC_INIT(X.YY.rcZ) in configure.in. + b. Run 'autoreconf -i' to generate the configure file again, with the + new release number. + c. Run './configure' to generate Makefile and dist/libcgroup.spec with + correct version numbers. + d. Run 'make dist' to create tarball. Fix Makefile.am files if + something goes wrong. + The tarball should contain everything needed for compilation with + simple sh, make and (optionally) rpmbuild, among others: + libcgroup-X.YY.rcZ/configure + libcgroup-X.YY.rcZ/dist/libcgroup.spec + e. Try to build rpms ('rpmbuild -ta libcgroup-X.YY.rcZ.tar.gz'), fix + errors in dist/libcgroup.spec.in file if something goes wrong. + f. Tag the pre-release in git. + g. Publish the pre-release libcgroup-X.YY.rcZ.tar.gz and announce it on + the libgroup-devel list. + h. Test the pre-release and go to a) if new one is needed. + During this period, ABI of newly introduced shared symbols is *not* + stable and may change, if there is very good reason to break it. + +5. Finally release official version using the same procedure as in step 3., + only without the .rcZ version number suffix. +6. Update topic on #libcgroup IRC channel. ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Libcg-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libcg-devel
