1.5 Release Cycle

[Ian MacLennan]

For a while now the responsibility of managing the 1.5 branch has fallen on the shoulders of Mark and I.  I have no major complaints about this and I think that despite the fact that we've had a few hiccups that we have managed this fairly well.

We've been working off of a release checklist document that we inherited that lists most necessary steps in the process of producing a release, from determining the name, to setting the date, to notifying the necessary parties, to creating the announcement and packaging, tagging, etc etc.

This list is a very good base on which to work from, and I have no major complaints besides the fact that it has become somewhat out of date and many items on the list no longer apply, especially in light of the recent restructuring.

I suppose the purpose of this email is to get some feedback on what should happen during a release cycle, who needs to be informed, and who should be involved in the process of making decisions regarding the 1.5 releases.

Another issue that I have raised is our nomenclature in regards to what is sufficient for a release to be considered a security release.

The current release cycle is broken down into a number of macro steps:
1. Setting date, name and type of release
2. Communication pre-check (check with WG coords for status, check with lead devs for status, inform dev work group, decision)
3. Communication pre-release (inform global mods, assign tasks to people available to help)
4. Trunk freeze and notice
5. Communication (frontpage announcement, update j.org/download.html, add version info to wiki)
6. pre-packaging (delivery & commit of language files, creating section on jcode, communicate URL to core list, pre-package & testing)
7. Final packaging (change version info & install check, add changelog line, package & upload, check packages, publish news, tag, unfreeze and removing install check)

So, here's my proposal:
1. setting date and name of release and type of release
    a. I propose that the discussion for setting the date of the release happen here, on this list.  Some discussion may need to happen in skype for speed sake, but the essence of these conversations will be copied here to this list so that it is publicly available.
    b. the release names are fairly predetermined as they are simply Yacqui numbers.  They will be posted in the notes for a.
    c. the type of release will be discussed privately on the security list.
    d. the following criteria will generally be used to make that determination:
        if there is a critical security issue such as those found in 1.5.5 and 1.5.12, the release type will be 'Critical Security Release'
        if there are other security issues of any sort, the release type will be 'Security Release'
        if there are no security issues at all that were fixed, the release type will be 'Maintenance Release'
    e. we should aim to have the release date be at least one week after the final decision to release is made.  At this point, we will go into soft freeze and no further language string changes will be made.  At this point, the TT coordinator will be notified who can then in turn contact internationalization times so they can build language packs, etc etc.  Soft freeze will be announced here and on the JBS list.
    f. In the event that there is a critical security issue, the timeline for release will be shortened accordingly.  If there is an urgent security issue, then fixes will be devised for the security issues and will be applied against the revision of the last release (not the latest svn).  We need to workout the mechanics of how this happens in terms of the release packager and deployment scripts - perhaps we can just revert any patches that have been committed when we are ready.  Communication regarding a critical security issue will most likely happen in private rather than on list for obvious reasons.

2. Communication pre-check
    a. It is unclear in the new structure who should be checked with for release.  Since all development of 1.5 is handled by the Joomla! Bug Squad, and Mark and I are the coordinators of JBS, I'm going to propose that Mark and I make the decisions as to when to release, and we will post here to give an opportunity for other members of the Production Working Group Leadership to object or offer input.
    b. If there are no objections within 24 hours we will set the release date to be one week from the current date.

3. Communication pre-release
    a. During this step, a courtesy note will be left in the Global Mod Skype chat with a link to the release discussion (on the list) to ensure they are aware of the upcoming release.
    b. Release tasks will be assigned in the release discussion.

4. Close trunk
    a. three days after the release decision, the trunk will be hard frozen and an announcement of such will be made here and on the JBS list.  At this point we
will trigger a package build so that we have packages to test.
    b. At this point, the TT coordinators should have any updated language packs submitted and they will be committed.
    There are two things I want to discuss related to this.  At the current time, we don't add the version check and version info until right before final security commit and packaging.  Should we think about doing that at this stage here?  Or are there compelling reasons not to?
    The other thing I want to propose for thought was the idea of having pre-packages available for wider testing instead of just having them available to the bug squad.  These would have no guarantee on them in terms of fitness for use and would not be the official release (if we did this I would say no to changing the version in the SVN, but we might add the install check), but it would allow wider testing of the package before release.  I'm not sold on this idea, but I'm thinking about it.

5. At this point we have four days with final packages to test.  During these four days the following happens:
    a. The release notes are created
    b. The download section is created on joomlacode
    c. The release is manually tested
    d. We run functional tests (see repo at http://joomlacode.org/svn/joomla/testing/trunk/functionaltest) on the package
    e. If we have unit tests that are in a usable state, we run the unit tests.
    f. If errors come up during testing we make necessary adjustments and repackage.  If we need to repackage, we should consider delaying final release until two days after the repackage.
    g. I would like to propose that we aim to have all security patches ready by the four days to go mark.  These packages would be distributed among trusted people for testing and comments.
    h. Any security announcements are created by the JSST.

6. Once the packages have been tested and are deemed ready, on the scheduled release date we do final commits of security patches and version and installation check and trigger package build.  When the packages are ready we trigger the deployment script, test the final packages from joomlacode (mostly for archive integrity), we publish the announcement on joomla.org and in the forum.  At the same time we publish the security announcement on developer.joomla.org. 
    a. When this is done, we tag the release, remove the install check, and make an unfrozen announcement on this list and on the JBS list.

7. Release is complete, we have a beer and relax.

I would appreciate thoughts, comments and input on this proposal.
Ian

[Mark Dexter]

Ian, this looks really good to me. Thanks. Mark

On Aug 3, 12:18 pm, Ian MacLennan <ian.maclen...@community.joomla.org>
wrote:

>     d. We run functional tests (see repo athttp://joomlacode.org/svn/joomla/testing/trunk/functionaltest) on the

> package
>     e. If we have unit tests that are in a usable state, we run the unit
> tests.
>     f. If errors come up during testing we make necessary adjustments and
> repackage.  If we need to repackage, we should consider delaying final
> release until two days after the repackage.
>     g. I would like to propose that we aim to have all security patches
> ready by the four days to go mark.  These packages would be distributed
> among trusted people for testing and comments.
>     h. Any security announcements are created by the JSST.
>
> 6. Once the packages have been tested and are deemed ready, on the scheduled
> release date we do final commits of security patches and version and
> installation check and trigger package build.  When the packages are ready
> we trigger the deployment script, test the final packages from joomlacode
> (mostly for archive integrity), we publish the announcement on

> joomla.organd in the forum.  At the same time we publish the security