98 lines
3.2 KiB
Plaintext
98 lines
3.2 KiB
Plaintext
=============================
|
|
Horde Release Process Notes
|
|
=============================
|
|
|
|
:Contact: horde@lists.horde.org
|
|
|
|
.. contents:: Contents
|
|
|
|
|
|
The steps to use when cutting a new release
|
|
===========================================
|
|
|
|
1. Examine ``*/docs/CHANGES`` files:
|
|
|
|
- Add the word SECURITY in front of any security-related changes,
|
|
and move them to the top, to draw attention to them.
|
|
|
|
- Cull out the most important ones, and prepare the text of an
|
|
announcement.
|
|
|
|
- Write the release announcements into the ``docs/RELEASE_NOTES`` file and
|
|
check if it parses with ``php -l docs/RELEASE_NOTES``.
|
|
|
|
As an extra effort to ensure completeness, you could also check the
|
|
changelogs for any changes that may not have been inserted in the
|
|
``*/docs/CHANGES`` file and integrate them into the above points.
|
|
|
|
2. Examine ``docs/*`` files, and update the version if this is a major
|
|
release. Minor releases should not change the versions in these files.
|
|
|
|
Add ``-alpha`` or ``-beta`` sentinels to the ``pear install`` instructions
|
|
if switching from stable release to pre-release, and vice versa.
|
|
|
|
3. Update the .pot file: ``horde-translation extract --module foo`` and commit
|
|
it.
|
|
|
|
4. Make sure your settings in ``components/config/conf.php`` are correct.
|
|
|
|
5. Make a "dry run" of the ``horde-components`` script by adding ``--pretend``
|
|
to the command line parameters.
|
|
|
|
6. Create the PEAR package releases using ``horde-components ./foo release``::
|
|
|
|
- For usage, use the ``--help`` flag.
|
|
|
|
7. Commit the web site (``horde-web`` Git repository):
|
|
|
|
- Push changes to ``config/versions.sqlite`` to update the version
|
|
information.
|
|
|
|
8. Add new version to bugs.horde.org if not added automatically by the release
|
|
script.
|
|
|
|
If releasing the first stable version after a release cycle, mark all
|
|
pre-release versions as inactive.
|
|
|
|
9. Bump version numbers of showstopper tickets that didn't go into the release,
|
|
then bump version number in the showstopper query on bugs.horde.org.
|
|
|
|
10. Update demo.horde.org
|
|
|
|
|
|
Guidelines for release cycles
|
|
=============================
|
|
|
|
* When switching between stable and unstable releases, make sure the release
|
|
state and release version in package.xml are correct.
|
|
|
|
* During unstable releases the release version must be checked for every
|
|
release, because the components scripts does automatically bump versions, but
|
|
doesn't switch versions when changing from alpha to beta to RC.
|
|
|
|
* During unstable releases check carefully the dependency versions. It may be
|
|
necessary to set an alpha/beta/RC version as the minimum version of a
|
|
dependency.
|
|
|
|
|
|
Example format for announcement messages
|
|
========================================
|
|
|
|
::
|
|
|
|
The Horde Team is pleased to announce the (first release candidate|official
|
|
release) of the [MODULE NAME] [MODULE DESCRIPTION] version [VERSION].
|
|
|
|
[MODULE DESCRIPTION]
|
|
|
|
[Barring any problems, this code will be released as [MODULE] [VERSION].
|
|
Testing is requested and comments are encouraged.
|
|
Updated translations would also be great.]
|
|
|
|
[[MODULE] version H3 ([VERSION]) is a major upgrade in the a.x release series,
|
|
including these enhancements:]
|
|
[The major changes compared to the [MODULE] version H3 (a.b) are:]
|
|
* [CHANGE 1]
|
|
* [CHANGE 2]
|
|
* ...
|