Server IP : 162.240.98.243 / Your IP : 3.133.131.191 Web Server : Apache System : Linux server.bti.yaw.mybluehostin.me 3.10.0-1160.119.1.el7.x86_64 #1 SMP Tue Jun 4 14:43:51 UTC 2024 x86_64 User : btiyawmy ( 1003) PHP Version : 7.2.34 Disable Function : NONE MySQL : OFF | cURL : ON | WGET : ON | Perl : ON | Python : ON | Sudo : ON | Pkexec : ON Directory : /usr/share/doc/cpanel-php74-horde-5.2.23/ |
Upload File : |
============================= 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] * ...