Release Procedure

 

Freezing the code

The first thing that needs to be done to start the process of a new ImpressCMS release, is to freeze the code that shall be used for the release. In order to do so, a message will need to be posted in the Current Release Forum to inform all the developers that we are now preparing for a release. We should announce this in the forum and give a 24 hours delay during which developers can finish adding what they want before the freeze of the code. Then, 2 situations can happen.

Start of a new release cycle

The start of a new Release Cycle is for example, when we first start to develop 1.1 or 1.2 version. When this happens, after the code is frozen, the ImpressCMS_Trunk is copied over to a new branch: core/branches/impresscms_{version_number}. This new branch will be used during all the release cycle (beta, rc, final...). A post will be made in the thread created earlier announcing that a new branch has been created for this new release cycle. Of course, development for future release can still go on in the Trunk.

New release within an existing release cycle

When we already are in a Release Cycle, the actual branch is frozen for new code until the release is actually made. For example, when starting the release process of 1.1 Beta 1, the impresscms_1.1 branch will be frozen until the release is made, after what bugs fixing can continue to be committed in that very branch.

Finalizing documents

Some documents will need to be reviewed for their accuracy (of course, in the impresscms_{version_number} branch).

  • /docs/install.html
  • /docs/language_changelog.txt
  • /upgrade/readme.txt
  • /release_notes.txt
  • /include/version.php - needs to be updated with the version name, build number and version status
  • /modules/system/icms_version.php - both 'version' and 'status_version' need to be updated, and  _CO_ICMS_WARNING_ALPHA, _CO_ICMS_WARNING_BETA or _CO_ICMS_WARNING_RC should be defined, depending on the pre-release you are making. These warnings are not needed for a final release.
* @version		$Id: version.php 897 2008-02-15 19:53:31Z malanciault $
*/

define("ICMS_VERSION_NAME",'ImpressCMS 1.1 RC3');

// For backward compatibility with XOOPS define("XOOPS_VERSION", ICMS_VERSION_NAME);

/* * Version Status * 1 = Alpha * 2 = Beta * 3 = RC * 10 = Final */

define("ICMS_VERSION_STATUS", 3);

/* * Build number * * Every release has its own build number, incrementable by 1 everytime we make a release */ define("ICMS_VERSION_BUILD", 13); ?>

Once these documents have been updated and committed back in our SVN, we need to edit the Change History for ImpressCMS and the Release_notes here on our wiki.

Tagging the branch

When the branch is ready for packaging, impresscms_{version_number} will be copied over the core/tags/impresscms_{version_number}-{version_status} in order to create a snapshot of the code to be released. This can be easily done with TortoiseSVN with these steps:

Or, using the command line: svn copy http://subversion.assembla.com/svn/impresscms/branches/impresscms_{version_number} http://subversion.assembla.com/svn/impresscms/tags/impresscms_{version_number}_{version_status}

Creating packages

Three different packages will need to be created.

Full package

The full package should contain the integral branch impresscms_{version_number}, after an SVN Export has been done. With TortoiseSVN, this is easily done with these steps:

If you are a fan of the command line: svn export http://subversion.assembla.com/svn/impresscms/branches/impresscms_{version_number} You will now have an impresscms_{version_number} folder which will be the full package of this release. Open this folder, select all files and folders inside it and create 2 archives, a zip and a tar.gz archives. The name of those files will need to be:

  • impresscms-{version_number}-{version-status}.zip
  • impresscms-{version_number}-{version-status}.tar.gz

Upgrade package

From previous minor version

The upgrade package needs a little bit more work to be done then the full package. First, this package needs to contains only the files that have changed since the latest release (e.g. 1.2.5 to 1.2.6).

TortoiseSVN can be used to export only those files that have changed or been added to the branch since the last release. Comparing Branches explains how to do this.

Once the package is ready, two archives will need to be created:

  • impresscms-{version_number}-to-{version_number}.zip
  • impresscms-{version_number}-to-{version_number}.tar.gz 

From previous major release

  The upgrade package from a previous major release typically contains the same files as a basic installation package, with a few exceptions:  

  • remove htdocs/mainfile.php
  • remove htdocs/install/
  • remove htdocs/cache/ and htdocs/templates_c/
  • remove htdocs/favicon.ico
  • move /upgrade to htdocs/

Once the package is ready, two archives will need to be created:

  • impresscms-{version_number}-to-{version_number}.zip
  • impresscms-{version_number}-to-{version_number}.tar.gz

Testing packages

The upgrade and the full packages will need to be fully tested by more then 2 people. The packages will be made available for download and an email will be sent to the ImpressCMS Developers mailing list with appropriate links so they can be tested for file integrity. A delay of 48 hours should be given to test the packages. If problems are found in the packages, fix will need to be made and committed in the impresscms_{version_number} branch, then the branch tagged again and the packages recreated all over again.

Show stoppers

For ANY of our releases, here are the areas that constitute a "show stopper". This means that if a problem is found in any of these, the problem needs to be fixed and the packages re-created.

  • If user can't login
  • If user can't register
  • If a problem is found which prevent a normal installation to be successful
  • If a problem is found which prevent a normal upgrade to be successful
  • If a security issue is found

Preparation of the Announcement

While the packages are being tested by the community, an announcement needs to be drafted which will have at least the following information:

  • Version number
  • Version status
  • Summary of the important changes, bugs, new features
  • Any important information any user should know

A model to follow can be found here. The announcements are prepared and published in the Project Announcement category of the community web site. All translators are recommended to subscribe to new submissions for that category.

Creating a new Release on SourceForge

Please note that only admins and release technicians can release the packages on SourceForge. If you would like to become a release technician, please send an email to contact at impresscms dot org.

  • In the ImpressCMS SourceForge project, select Admin > File Releases
  • In the ImpressCMS Core package, click on Add Release to create a new release
  • Input the New release name, which needs to be ImpressCMS
  • In the Paste The Notes In field, paste the content of /release_notes.txt
  • In the Paste The Change Log In field, paste the content of the {version-number}-{version-status} section of /docs/changelog.txt
  • Select the checkbox Preserve my pre-formatted text
  • Hit the Submit/Refresh button

Uploading the packages in the release on SourceForge

Then you need to upload all the packages in the Sourceforge FTP server. You can upload new files using anonymous FTP to upload.sourceforge.net in the incoming directory. When you are done uploading, just hit the refresh button to see the new files. Further information regarding this process may be found in our Guide to the File Release System. In the list of files displayed on that page, select all the files that you uploaded and hit the Add Files and/or Refresh View

Email release notice

In the Step 4 of the page, click the I'm sure checkbox and hit the Send Notice button in order to notify the people who are monitoring this package.

Announcement

Once the packages are publicly available on SourceForge, the announcement made earlier needs to be published on as many international sites as possible, but at least:

 Press Releases should also be made at all other relevant sites, along with updates where required for example version numbers and features on Hotscripts and similar websites.

 

 

Last modified on 2012/4/22 by Anonymous
Comments
The comments are owned by the poster. We aren't responsible for their content.