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.
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.
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.
Some documents will need to be reviewed for their accuracy (of course, in the impresscms_{version_number} branch).
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.
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}
Three different packages will need to be created.
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:
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:
The upgrade package from a previous major release typically contains the same files as a basic installation package, with a few exceptions:
Once the package is ready, two archives will need to be created:
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.
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.
While the packages are being tested by the community, an announcement needs to be drafted which will have at least the following information:
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.
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.
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
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.
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 2021/9/19 by skenow
|