Release Process

From OpenLaszlo

(Difference between revisions)

Current revision

These are the steps required to create a new release of OpenLaszlo:

Define the release

The release will have been scheduled and the Jira tasks for the release will have been assigned and completed in the development branch.

[edit]

Declare the release

The Project Manager will determine that the development branch is sufficiently complete that it is ready to become a release candidate:

MINIMAL CRITERIA

No P0 bugs
All doc changes in place
Release Notes complete
No stop-ship bugs
QA pass complete
Build has been stable "for a while"

[edit]

Create a branch

The Branch Manager will create a branch for the release. (See Creating a Branch.) Initially the branch will be designated as a release candidate or RC. When the above criteria are met, and the final production build is to be made, the release will be designated as Production.

[edit]

Address QA/Beta-test Issues

The Project Manager will determine when QA and Beta-test issues warrant fixes in the release candidate. If so, the Branch Manager will integrate those fixes from the development branch to the release branch (see Integrating changes to a branch) and create new builds for further testing.

[edit]

Create a production build

[edit]

Update the Release Notes

Create a JIRA filter for bugs 'Actually Fixed In' this release. Make sure to SHARE the filter with ALL.

Use that filter to ensure that all the bugs 'Actually Fixed In' this release also have this release in their 'Fix Version' field, because the latter is what the Jira "Release Notes" report looks at.

Verify the Jira "Release Notes" report lists all the bugs fixed in the release, along with our custom 'Release Note Text' fields.

Update release-notes.html to reference that report and summarize what is new in this build.

Be sure to syntax-check the update to ensure it is valid HTML

Check in the update to trunk and integrate it to the branch being released.

[edit]

Declare production

When the release candidate has met the release criteria, the Project Manager will declare a Production build. The Build Manager will update versions.xml (in the branch source) by changing RC to Production to reflect that and create a new build. (If there are further releases expected out of this branch, you should also add an entry for the next point release marked as Latest.)

Kick off the production build on the build machine by specifying the branch and version:

 [svnbuild@linux-builder ~ 14:23:39]$ nohup ./nightly-go.sh branches/pagan-deities 15671 &

Note: nightly-go.sh will not rebuild if the revision number has not changed. At the very least you need to check in a new version of versions.xml that contains the updated build number.

[edit]

Verify build

The Branch Manager will verify a successful build and deployment to Labs.

[edit]

Tag the release

The Branch Manager will tag the release.

   > svn copy -r<release branch revision> \
   -m "Create <release number> release tag from <release branch>@<release branch revision>" \
   http://svn.openlaszlo.org/openlaszlo/branches/<release branch> \
   http://svn.openlaszlo.org/openlaszlo/tags/<release number>

Normally, <release branch revision> will be the Last Changed Rev: reported by svn info for the branch.

[edit]

Publish the release

The Branch Manager will publish the installers, README, LICENSE and release-notes on Download.

 ssh openlaszlo@download.openlaszlo.org
 cd  download.openlaszlo.org
 mkdir <release number>
 cd <release number>
 cp -p ../nightly/<release build version>-openlaszlo-branches-<release branch>/*  .

[edit]

Release Numbering

The convention is to name the release to 3 digits, but create an alias from the 2-digit name to the latest 'point release'. E.g., the first release of 4.3 was 4.3.0, so the directory on download appears as follows:

 4.3@ -> 4.3.0
 
 4.3.0:
 4.3.0%20branches%2f4.3%4013582%20(13583)
 LICENSE.rtf
 LICENSE.txt
 openlaszlo-4.3.0-osx-dev-install.dmg
 openlaszlo-4.3.0-servlet.war
 openlaszlo-4.3.0-src.tar.gz
 openlaszlo-4.3.0-unix.tar.gz
 openlaszlo-4.3.0.war
 openlaszlo-4.3.0-windows-dev-install.exe*
 README.core.txt
 README.txt
 release-notes.html

And when 4.3.1 is released, it will have its own directory, but the 4.3 symbolic link will be updated to point to 4.3.1.

[edit]

Create .torrents

 #!/bin/bash
 # Build and publish torrents of the installers
 #
 # NOTE [2010-03-22 ptw] (OBI-65) Must be run on the downloads server in the directory of the release you want to publish
 #
 # Copyright 2010 Laszlo Systems, Inc.
 
 CWD=`pwd`
 for file in *.war *.gz *.dmg *.exe; do
     mktorrent -a http://tracker.openlaszlo.org/announce.php ${CWD}/${file}
     btcli add -d ${CWD} ${file}.torrent
 done

[edit]

Post Production

When you create production build by recording it in versions.xml, you should simultaneously create an entry to reflect the next possible "Point Release" that could happen in the branch. This will prevent any accidental build that could be confused with the production build.

[edit]

Deploy build

For a public release, The Branch Manager and or Web Manager will deploy the build to Stable, point http://www.openlaszlo.org/lps<release number> to the new deployment, and verify that deployment.

Virtual Host

You'll note that on openlaszlo.org, ~laszlo/public_html/openlaszlo.conf has (in the vritualhost block that includes www.openlaszlo.org):

   JkMount /lps4.2 dlxapp1
   JkMount /lps4.2/* dlxapp1

This implies that the worker called dlxapp1 is used for that url. If you are making a new release, you will need to add a new JkMount. Consider trimming any mount points that are no longer needed (e.g., any that are for releases that are no longer being maintained). You will have to restart the openlaszlo.org Apache server for it to see your new mount points.

The worker definition can be found in /etc/httpd/conf.d/openlaszlo.properties (important info shown only..)

   worker.dlxapp1.port=8009
   worker.dlxapp1.host=dlxapp1.laszlomail.com

Meaning that it is hosted on a machine called dlxapp1.laszlomail.com.

Tomcat Server

   ps -fwwp `netstat -lnp|grep 8009|awk '{print $NF}'|awk -F/ '{print $1}'`

/home/laszlo/opt/jakarta-tomcat-5.0.28 and the subdir /home/laszlo/opt/jakarta-tomcat-5.0.28/conf/Catalina/localhost

Note the file lps4.2.xml in that directory contains a pointer to a lps distro:

   <?xml version='1.0' encoding='utf-8'?>
   <Context docBase="/home/laszlo/webapps/openlaszlo-4.2.0" path="/lps4.2">
   </Context>

(but don't update it until you have installed the corresponding .war). If you are making a new release, you will have to make a new .xml file, patterned on an existing one. Consider removing any old, unsupported configurations. The tomcat server is configured to notice when configuration files change and automatically reload them.

[edit]

Install Distribution

Copy the distro to the typical place (these steps must be done by the user `laszlo`)

cd /home/laszlo/webapps
curl -O http://fast.download.openlaszlo.org/<release>/openlaszlo-<release>.war
mkdir openlaszlo-<revision number>
cd openlaszlo-<revision number>
unzip ../openlaszlo-<revision number>.war

then change the docBase in /home/laszlo/opt/jakarta-tomcat-5.0.28/conf/Catalina/localhost/<release>.xml to your new one, save the file - tomcat will note that it changed and reload automatically.

[edit]

Update the demos app

Copy the distribution into the openlaszlo_demos webapp, so that the demos (http://www.openlaszlo.org/lps_demos/...) will be running the latest release:

cd openlaszlo-demos
unzip ../openlaszlo-<revision number>.war

[I had trouble getting tomcat to pick this up. What I finally did was edit the lps_demos.xml file to 1st point to the new release, then empty the lps_demos dir, unzip the new release into it, and finally point the lps_demos.xml back at the lps_demos directory. (I tried stop/starting the server, reloading, etc. but I couldn't convince it to stop delivering old, cached versions.)]

[edit]

Update the Web Site

The Web Manager will update openlaszlo.org to publicize the new release.

Use drupal. Log into Drupal. Then, go to the admin page. From their, click on Manage Content and update the following pages:

[edit]

Download

Update current release table and para underneath
Update current builds and sizes for builds
Verify links in Release Notes
Verify links to downloads

[edit]

Documentation

Update release documentation column title
Update google search options

[edit]

OpenLaszlo Release Archive

Add old version to the table, as well as the current version (copy format from Download page and remove the comment lines around extra column, which is needed here)

[edit]

OpenLaszlo Front Page

Modify the front_page module to add the new release graphic (http://www.openlaszlo.org/admin/settings/front). To get there another way, choose Advanced Front Page Settings under Administer->Site Configuration in Drupal. Changes must be made in all 3 places: for authenticated users, for anonymous users, and for admin.

The graphic should be stored here: /home/laszlo/public_html/www.openlaszlo.org/images.

[edit]

Announce the Release

Go to the OpenLaszlo.org forums, and add an entry under the Announcements section
Cotweet the announcement on twitter
Send an email to laszlo-user, laszlo-dev, and laszlo-announce mailing lists
Send an email to laszlo@laszlosystems.com
Create a blog entry on weblog, which eventually appears on the front page of OpenLazlo.org
Press release (if required for that release)

Retrieved from "http://wiki.openlaszlo.org/Release_Process"

   [svnbuild@linux-builder ~ 14:23:39]$ nohup ./nightly-go.sh branches/pagan-deities 15671 &
+'''Note''': nightly-go.sh will not rebuild if the revision number has not changed. At the very least you need to check in a new version of versions.xml that contains the updated build number.
 ===Verify build===

the premier open-source platform for rich internet applications

Personal tools

Wiki Navigation

Wiki Search

Toolbox

Views

Release Process

From OpenLaszlo

Current revision

Contents

Define the release

Declare the release

Create a branch

Address QA/Beta-test Issues

Create a production build

Update the Release Notes

Declare production

Verify build

Tag the release

Publish the release

Release Numbering

Create .torrents

Post Production

Deploy build

Install Distribution

Update the demos app

Update the Web Site

Download

Documentation

OpenLaszlo Release Archive

OpenLaszlo Front Page

Announce the Release