MozillaWiki - User contributions [en]

Calendar:HowToRelease

2008-03-17T17:04:24Z

Ause: /* '''Release Process''' */

= '''Release Process''' =
== Overview ==
This is a short summery of steps required to do a release of Sunbird/Lightning. For simplicity, these steps are expected to be executed in the order mentioned here. Each step will have a more detailed section below.

To prepare for a release:
* Create a branch in mozilla repository
* Create a branch in l10n repository
* Change Tinderboxes to build form that branch
* Change the Version Number
* Create localized version of Lightning (to be done in the build - see [https://bugzilla.mozilla.org/show_bug.cgi?id=352546 Bug 352546])
* Tag files on the branch to make a RC if required

When the final RC gets approved:
* Tag files on the branch with a release tag
* Create Mac universal binaries (to be done in the build too?)
* Move stuff around on stage server

== Create a branch ==
NOTES:
* ${PRODUCT_TAG} is the header for the BRANCH - for sunbird 0.7 this will de SUNBIRD_0_7, other releases should follow the same convention
* ${BRANCH_TAG} is made by appending _BRANCH to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_BRANCH
* ${RC_TAG} is made by appending _RC to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_RC
* ${RELEASE_TAG} is made by appending _RELEASE to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_RELEASE
* If you intend to see changes made for this release, esp. the fixes, in any later release, keep in mind to also commit them to the regular development branch, e.g.
tools/cross-commit --trunk --moz18 --branch=${PRODUCT_TAG}_BRANCH ...

=== mozilla cvs repository ===
1. Create a branch from the branch you are releasing from. This creates a ${PRODUCT_TAG}_BRANCH from the MOZILLA_1_8_BRANCH,
<pre>
cvs co -r MOZILLA_1_8_BRANCH mozilla/client.mk

make -f mozilla/client.mk checkout MOZ_CO_PROJECT="mail,calendar" MOZ_CO_MODULE="mozilla/tools/update-packaging"

cd mozilla

cvs tag -b ${PRODUCT_TAG}_BRANCH mozilla

</pre>
NOTE:
* Tagging the tree created with "make checkout" just creates a branch on those files required. This to prefer to polluting all files with rtag if possible

2. Test that the branch was properly created by checking out from the branch.
<pre> cvs co -r ${BRANCH_TAG}_BRANCH mozilla </pre>

=== l10n cvs repository ===

* Note that you will need L10N access to do this
<pre>
# Branch Locales like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT_L10N} rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH l10n
</pre>

From now on, changes meant to apper in the release are done on this branch.

== Change Tinderboxes for Release ==

"tinderbox-config.pl" and the according "mozconfig" files have to be changed to let the tinderboxes pick up the release branch and do "release builds".

NOTES:
* be sure to make these changes on the cvs branch the desired tinderbox picks up. These are MOZILLA_1_8_BRANCH for regular tinderboxes and MOZILLA_1_8_BRANCH_l10n for the l10n tinderboxes.

The following sample shows the changes done for linux when switching back from "release mode" to "nightly".

TODO: place the changes done for 0.7 here

<pre>
Index: tinder-config.pl
===================================================================
RCS file: /cvsroot/mozilla/tools/tinderbox-configs/sunbird/linux/tinder-config.pl,v
retrieving revision 1.26.2.8
retrieving revision 1.26.2.9
diff -u -r1.26.2.8 -r1.26.2.9
--- tinder-config.pl 24 May 2007 16:56:07 -0000 1.26.2.8
+++ tinder-config.pl 28 Jun 2007 20:21:07 -0000 1.26.2.9
@@ -49,8 +49,8 @@
# Tests
$CleanProfile = 1;
$ResetHomeDirForTests = 1;
-$ProductName = "Sunbird";
-#$ProductName = 'Calendar';
+#$ProductName = "Sunbird";
+$ProductName = 'Calendar';
$VendorName = 'Mozilla';

#$RunMozillaTests = 1; # Allow turning off of all tests if needed.
@@ -166,13 +166,8 @@

$LocalizationVersionFile = 'calendar/sunbird/config/version.txt';

-#%WGetFiles = (
-# "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/latest-mozilla1.8/sunbird-%version%.en-US.linux-i686.tar.gz" =>
-# "/builds/tinderbox/Sb-Mozilla1.8-l10n/Linux_2.4.21-37.EL_Clobber/sunbird.tar.gz"
-# );
-
%WGetFiles = (
- "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/candidates/0.5rc1/sunbird-%version%.en-US.linux-i686.tar.gz" =>
+ "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/latest-mozilla1.8/sunbird-%version%.en-US.linux-i686.tar.gz" =>
"/builds/tinderbox/Sb-Mozilla1.8-l10n/Linux_2.4.21-37.EL_Clobber/sunbird.tar.gz"
);

@@ -190,8 +185,8 @@
$BuildTree = 'Mozilla1.8-l10n';

#$BuildName = '';
-#$BuildTag = 'MOZILLA_1_8_BRANCH';
-$BuildTag = 'SUNBIRD_0_5_RELEASE';
+$BuildTag = 'MOZILLA_1_8_BRANCH';
+#$BuildTag = 'SUNBIRD_0_5_RELEASE';
#$BuildConfigDir = 'mozilla/config';
#$Topsrcdir = 'mozilla';
</pre>

NOTES:
* All this doesn't help too much without changing mozilla/client.mk on the according brach, e.g. :

<pre>
--- client.mk 27 Jun 2007 18:17:42 -0000 1.245.2.38
+++ client.mk 27 Sep 2007 10:34:18 -0000
@@ -252,21 +252,21 @@ MODULES_all :=
mozilla/other-licenses/7zstub \
$(NULL)

#######################################################################
# Checkout Tags
#
# For branches, uncomment the MOZ_CO_TAG line with the proper tag,
# and commit this file on that tag.
-MOZ_CO_TAG = MOZILLA_1_8_BRANCH
+MOZ_CO_TAG = SUNBIRD_0_7_BRANCH
NSPR_CO_TAG = NSPR_4_6_7_RTM
NSS_CO_TAG = NSS_3_11_5_WITH_CKBI_1_64_RTM
-LDAPCSDK_CO_TAG = MOZILLA_1_8_BRANCH
-LOCALES_CO_TAG = MOZILLA_1_8_BRANCH
+LDAPCSDK_CO_TAG = SUNBIRD_0_7_BRANCH
+LOCALES_CO_TAG = SUNBIRD_0_7_BRANCH

BUILD_MODULES = all

#######################################################################
# Defines
#
CVS = cvs
comma := ,

</pre>

== Change the Version Number ==

* You check out the branch you just created - use standard "check out code from mozilla cvs method", just substitute in the new branch for your branch parameter
* On this branch, you change the follwing:
* calendar/sunbird/app/module.ver
* calendar/sunbird/config/version.txt
* Then you:
<pre>cvs -d ${CVSROOT} co -r ${PRODUCT_TAG}_BRANCH\
mozilla/calendar/sunbird/app/module.ver mozilla/calendar/sunbird/config/version.txt
</pre>

== Tag RC ==
At a specific point in time, when you feel it's right do
<pre>
cvs rtag -r ${PRODUCT_TAG}_BRANCH ${PRODUCT_TAG}_RCn mozilla
cvs rtag -r ${PRODUCT_TAG}_BRANCH ${PRODUCT_TAG}_RCn l10n
</pre>

of cause you can use something like "..._RCn" where "n" is the number of your release candidate.

== Create Mac universal binaries ==

Mac universal binaries are now created by the tinderbox.

== Pushing builds to the release tree ==
=== Adding links to bouncer ===
Make sure all files you're pushing to the release tree have their according bouncer link set up. More about this can be found here: [https://bugzilla.mozilla.org/show_bug.cgi?id=421555 add bouncer links for 0.8]

=== Sunbird ===
For the 0.7 release the required files were copied from the nightly directories and collected in a 0.7-candidates directory still in the nightly tree (flat structure, no renaming). Once all desired languages and platforms are there, a script exists to deliver them into the expected structure (platform/language) in the release tree and do the renaming.

TODO: provide de-personalized version of this script

TODO: provide usage example

TODO: make this script fix access rights and cretate MD5SUM files

TODO: rewrite script as new stage server doesn't allow local execution

=== Lightning ===

Lightning builds now create localized .xpi

== Providing updates for Sunbird ==
With the changes to the tinderboxe configuration (TODO: link to tb changes) also creation of update files (*.mar) gets enabled. While the complete updates are provided and uploaded by the tinderboxes, creating partial updates requires some manual work (see [[Software_Update:GeneratingSnippetsAndPartialsForReleases#Creating_updates |patcher2]]).

TODO: insert patcher2 config for sunbird

NOTE:
These update files can be tested manually as described in [[Software_Update:GeneratingSnippetsAndPartialsForReleases#How_Firefox.2FThunderbird_updates_are_tested]] .
Once the partial .mar are created and uploaded to the stage server, the according update information (snippets) need to be pushed to the AUS server.

helpfull links:
* [[Software_Update:GeneratingSnippetsAndPartialsForReleases| patcher2]]
* [[AUS|AUS overview]]
* [[Software_Update:Nightly_update_infrastructure|updates for nightlies]]

== More things not covered here yet ==
* [http://wiki.mozilla.org/index.php?title=Calendar:Sunbird_Updates auto update] and the according {{bug|381420}}
* [http://wiki.mozilla.org/Build:CommunitySelfHelp talkback changes] required for a version change

------------------------------------------------------

= '''Release Process Old Page''' =
keeping as reference for now - probaly remove when reworking is done.
------------------------------------------------------

== Create a branch ==
1. Create a branch from the branch you are releasing from this creates a ${PRODUCT_TAG}_BRANCH from the MOZILLA_1_8_BRANCH, you also need to note the time this was done on a page like [[Calendar:Release:Sunbird_0.5]].
<pre>
cvs rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH mozilla
Note time this is done: May 22, 21:37 CDT</pre>
2. Test that the branch was properly created by checking out from the branch.
<pre> cvs co -r ${BRANCH_TAG}_BRANCH mozilla/calendar </pre>

== Change the Version Number ==
* You check out the branch you just created - use standard "check out code from mozilla cvs method", just substitute in the new branch for your branch parameter
* On this branch, you change the follwing:
* calendar/sunbird/app/module.ver
* calendar/sunbird/config/version.txt
* Then you:
<pre>cvs -d ${CVSROOT} co -r ${PRODUCT_TAG}_BRANCH\
mozilla/calendar/sunbird/app/module.ver mozilla/calendar/sunbird/config/version.txt
</pre>

==Create a minibranch==
<pre>
cvs tag -b ${PRODUCT_TAG}_MINIBRANCH calendar/sunbird/app/module.ver \
calendar/sunbird/config/version.txt
cvs up -r ${PRODUCT_TAG}_MINIBRANCH calendar/sunbird/app/module.ver \
calendar/sunbird/config/version.txt
cvs ci -m"bumping version number on calendar/sunbird on minibranch only"
</pre>

* remove firefox stuff from calendar/lightning/install.rdf

== Tag the release ==
* run "date" before you start and use this as date stamp.
* the date should be in UTC and have this format: "yyyy-mm-dd hh:mm +0000"
* You need to use an RC here in case we have RC builds that way RCs will move forward to the release (you can have multiple RC's but there is only one release) so ${RC} becomes 1 for the first attempt to release 0.5
<pre>
screen
cd .. (one up from mozilla)
mkdir -p tags/${PRODUCT_TAG}_RC${RC}
cd tags && ln -s ${PRODUCT_TAG}_RC${RC} ${PRODUCT_TAG}_RELEASE && \
ln -s ${PRODUCT_TAG}_RC${RC} ${PRODUCT_TAG}_RELEASE
</pre>
* Next, check out mozilla/client.mk and any <something>/config/mozconfig files you need with statements like this:
<pre>
cvs co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
mozilla/client.mk
becomes: cvs co -r ${PRODUCT_TAG}_BRANCH -D "2007-05-23 04:00 +0000" mozilla/client.mk
</pre>
* Next, you follow these steps:
<pre>
# pull version files from the version bump minibranch
cvs up -r ${PRODUCT_TAG}_MINIBRANCH ${APP}/app/module.ver \
${APP}/config/version.txt config/milestone.txt

# Create the tag.
cvs tag ${PRODUCT_TAG}_RELEASE 2>&1 | tee ../${PRODUCT_TAG}_RELEASE.log
# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RELEASE.log

# Create the RC tag.
cvs tag ${PRODUCT_TAG}_RC${RC} 2>&1 | tee ../${BRANCH_TAG}_RC${RC}.log
# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RC${RC}.log

# Create a minibranch for the pull scripts so we can change them without
# changing anything on the original branch.
cvs tag -b ${PRODUCT_TAG}_MINIBRANCH client.mk

# Update client.mk to the minibranch you just created.
cvs up -r ${PRODUCT_TAG}_MINIBRANCH client.mk

# Add the new product tag to the client.mk - need to replace the current branch ID
sed "s/${MOZILLA_1_8_BRANCH}/${PRODUCT_TAG}_RELEASE/g" client.mk > client.mk.tmp
mv client.mk.tmp client.mk

# Verify that client.mk only has the changes you expect
cvs diff -u client.mk
# Verify that client.mk has its sticky tag set properly.
cvs status client.mk
cvs commit -m "For $PRODUCT $VERSION, redirect client.mk onto the ${PRODUCT_TAG}_RELEASE tag." client.mk

# Move the release tag onto the modified version of the pull scripts.
# Note that you may have to wait to gain a lock, that is normal.
cvs tag -F ${PRODUCT_TAG}_RELEASE client.mk
cvs tag -F ${PRODUCT_TAG}_RC${RC} client.mk
</pre>

=== Tag Talkback===
* '''NOTE:''' to do this, you need access to talkback, currently only lilmatt has that access on our team.
<pre>
# Create the mofo tag directory.
cd ~cltbld/tags/${PRODUCT_TAG}_RC${RC}
mkdir mofo/
cd mofo/

# Branch Talkback like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT}/mofo rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH mofo

# Check out the talkback files from the branch you want to tag.
cvs -d :ext:cltbld@cvs.mozilla.org:/mofo co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
talkback/fullsoft 2>&1 | tee checkout-output.log

# Create the tag.
cd talkback/fullsoft/
cvs tag ${PRODUCT_TAG}_RELEASE 2>&1 | tee ../${PRODUCT_TAG}_RELEASE.log

# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RELEASE.log
</pre>

=== Tag L10N ===
* Note that you will need L10N access to do this
<pre>
# Create the l10n tag directory.
cd ~cltbld/tags/${PRODUCT_TAG}_RELEASE
mkdir l10n/
cd l10n/

# Branch Locales like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT}/l10n rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH l10n

# Grab list of shipped locales
LOCALES=`awk '{print $1}' < ../cvsroot/mozilla/calendar/locales/shipped-locales`

# Check out the l10n files from the branch you want to tag.
(for l in $LOCALES
do
cvs -d ${CVSROOT}/l10n co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
l10n/${l}
done) 2>&1 | tee checkout-output.log

cd l10n/
</pre>

Use lilmatt's magic L10N script to compile Lightning into Locales. You can find the script in {{bug|352546}}. We will check it into the main tree somewhere (suggested name: m/c/lilmattsmagicbuildtricks). You need to update the .dtd and .properties filenames for the current release.

==Push tag forward on updated l10n files==
In the <code>l10n</code> directory where you originally tagged l10n...
cvs up -r SUNBIRD_0_5_BRANCH
cvs tag -F SUNBIRD_0_5_RELEASE

Calendar:HowToRelease

2008-03-05T07:45:18Z

Ause: /* Change Tinderboxes for Release */

= '''Release Process''' =
== Overview ==
This is a short summery of steps required to do a release of Sunbird/Lightning. For simplicity, these steps are expected to be executed in the order mentioned here. Each step will have a more detailed section below.

To prepare for a release:
* Create a branch in mozilla repository
* Create a branch in l10n repository
* Change Tinderboxes to build form that branch
* Change the Version Number
* Create localized version of Lightning (to be done in the build - see [https://bugzilla.mozilla.org/show_bug.cgi?id=352546 Bug 352546])
* Tag files on the branch to make a RC if required

When the final RC gets approved:
* Tag files on the branch with a release tag
* Create Mac universal binaries (to be done in the build too?)
* Move stuff around on stage server

== Create a branch ==
NOTES:
* ${PRODUCT_TAG} is the header for the BRANCH - for sunbird 0.7 this will de SUNBIRD_0_7, other releases should follow the same convention
* ${BRANCH_TAG} is made by appending _BRANCH to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_BRANCH
* ${RC_TAG} is made by appending _RC to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_RC
* ${RELEASE_TAG} is made by appending _RELEASE to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_RELEASE
* If you intend to see changes made for this release, esp. the fixes, in any later release, keep in mind to also commit them to the regular development branch, e.g.
tools/cross-commit --trunk --moz18 --branch=${PRODUCT_TAG}_BRANCH ...

=== mozilla cvs repository ===
1. Create a branch from the branch you are releasing from. This creates a ${PRODUCT_TAG}_BRANCH from the MOZILLA_1_8_BRANCH,
<pre>
cvs co -r MOZILLA_1_8_BRANCH mozilla/client.mk

make -f mozilla/client.mk checkout MOZ_CO_PROJECT="mail,calendar" MOZ_CO_MODULE="mozilla/tools/update-packaging"

cd mozilla

cvs tag -b ${PRODUCT_TAG}_BRANCH mozilla

</pre>
NOTE:
* Tagging the tree created with "make checkout" just creates a branch on those files required. This to prefer to polluting all files with rtag if possible

2. Test that the branch was properly created by checking out from the branch.
<pre> cvs co -r ${BRANCH_TAG}_BRANCH mozilla </pre>

=== l10n cvs repository ===

* Note that you will need L10N access to do this
<pre>
# Branch Locales like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT_L10N} rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH l10n
</pre>

From now on, changes meant to apper in the release are done on this branch.

== Change Tinderboxes for Release ==

"tinderbox-config.pl" and the according "mozconfig" files have to be changed to let the tinderboxes pick up the release branch and do "release builds".

NOTES:
* be sure to make these changes on the cvs branch the desired tinderbox picks up. These are MOZILLA_1_8_BRANCH for regular tinderboxes and MOZILLA_1_8_BRANCH_l10n for the l10n tinderboxes.

The following sample shows the changes done for linux when switching back from "release mode" to "nightly".

TODO: place the changes done for 0.7 here

<pre>
Index: tinder-config.pl
===================================================================
RCS file: /cvsroot/mozilla/tools/tinderbox-configs/sunbird/linux/tinder-config.pl,v
retrieving revision 1.26.2.8
retrieving revision 1.26.2.9
diff -u -r1.26.2.8 -r1.26.2.9
--- tinder-config.pl 24 May 2007 16:56:07 -0000 1.26.2.8
+++ tinder-config.pl 28 Jun 2007 20:21:07 -0000 1.26.2.9
@@ -49,8 +49,8 @@
# Tests
$CleanProfile = 1;
$ResetHomeDirForTests = 1;
-$ProductName = "Sunbird";
-#$ProductName = 'Calendar';
+#$ProductName = "Sunbird";
+$ProductName = 'Calendar';
$VendorName = 'Mozilla';

#$RunMozillaTests = 1; # Allow turning off of all tests if needed.
@@ -166,13 +166,8 @@

$LocalizationVersionFile = 'calendar/sunbird/config/version.txt';

-#%WGetFiles = (
-# "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/latest-mozilla1.8/sunbird-%version%.en-US.linux-i686.tar.gz" =>
-# "/builds/tinderbox/Sb-Mozilla1.8-l10n/Linux_2.4.21-37.EL_Clobber/sunbird.tar.gz"
-# );
-
%WGetFiles = (
- "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/candidates/0.5rc1/sunbird-%version%.en-US.linux-i686.tar.gz" =>
+ "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/latest-mozilla1.8/sunbird-%version%.en-US.linux-i686.tar.gz" =>
"/builds/tinderbox/Sb-Mozilla1.8-l10n/Linux_2.4.21-37.EL_Clobber/sunbird.tar.gz"
);

@@ -190,8 +185,8 @@
$BuildTree = 'Mozilla1.8-l10n';

#$BuildName = '';
-#$BuildTag = 'MOZILLA_1_8_BRANCH';
-$BuildTag = 'SUNBIRD_0_5_RELEASE';
+$BuildTag = 'MOZILLA_1_8_BRANCH';
+#$BuildTag = 'SUNBIRD_0_5_RELEASE';
#$BuildConfigDir = 'mozilla/config';
#$Topsrcdir = 'mozilla';
</pre>

NOTES:
* All this doesn't help too much without changing mozilla/client.mk on the according brach, e.g. :

<pre>
--- client.mk 27 Jun 2007 18:17:42 -0000 1.245.2.38
+++ client.mk 27 Sep 2007 10:34:18 -0000
@@ -252,21 +252,21 @@ MODULES_all :=
mozilla/other-licenses/7zstub \
$(NULL)

#######################################################################
# Checkout Tags
#
# For branches, uncomment the MOZ_CO_TAG line with the proper tag,
# and commit this file on that tag.
-MOZ_CO_TAG = MOZILLA_1_8_BRANCH
+MOZ_CO_TAG = SUNBIRD_0_7_BRANCH
NSPR_CO_TAG = NSPR_4_6_7_RTM
NSS_CO_TAG = NSS_3_11_5_WITH_CKBI_1_64_RTM
-LDAPCSDK_CO_TAG = MOZILLA_1_8_BRANCH
-LOCALES_CO_TAG = MOZILLA_1_8_BRANCH
+LDAPCSDK_CO_TAG = SUNBIRD_0_7_BRANCH
+LOCALES_CO_TAG = SUNBIRD_0_7_BRANCH

BUILD_MODULES = all

#######################################################################
# Defines
#
CVS = cvs
comma := ,

</pre>

== Change the Version Number ==

* You check out the branch you just created - use standard "check out code from mozilla cvs method", just substitute in the new branch for your branch parameter
* On this branch, you change the follwing:
* calendar/sunbird/app/module.ver
* calendar/sunbird/config/version.txt
* Then you:
<pre>cvs -d ${CVSROOT} co -r ${PRODUCT_TAG}_BRANCH\
mozilla/calendar/sunbird/app/module.ver mozilla/calendar/sunbird/config/version.txt
</pre>

== Tag RC ==
At a specific point in time, when you feel it's right do
<pre>
cvs rtag -r ${PRODUCT_TAG}_BRANCH ${PRODUCT_TAG}_RCn mozilla
cvs rtag -r ${PRODUCT_TAG}_BRANCH ${PRODUCT_TAG}_RCn l10n
</pre>

of cause you can use something like "..._RCn" where "n" is the number of your release candidate.

== Create Mac universal binaries ==

Mac universal binaries are now created by the tinderbox.

== Pushing builds to the release tree ==
=== Sunbird ===
For the 0.7 release the required files were copied from the nightly directories and collected in a 0.7-candidates directory still in the nightly tree (flat structure, no renaming). Once all desired languages and platforms are there, a script exists to deliver them into the expected structure (platform/language) in the release tree and do the renaming.

TODO: provide de-personalized version of this script

TODO: provide usage example

TODO: make this script fix access rights and cretate MD5SUM files

=== Lightning ===

Lightning builds now create localized .xpi

== Providing updates for Sunbird ==
With the changes to the tinderboxe configuration (TODO: link to tb changes) also creation of update files (*.mar) gets enabled. While the complete updates are provided and uploaded by the tinderboxes, creating partial updates requires some manual work (see [[Software_Update:GeneratingSnippetsAndPartialsForReleases#Creating_updates |patcher2]]).

TODO: insert patcher2 config for sunbird

NOTE:
These update files can be tested manually as described in [[Software_Update:GeneratingSnippetsAndPartialsForReleases#How_Firefox.2FThunderbird_updates_are_tested]] .
Once the partial .mar are created and uploaded to the stage server, the according update information (snippets) need to be pushed to the AUS server.

helpfull links:
* [[Software_Update:GeneratingSnippetsAndPartialsForReleases| patcher2]]
* [[AUS|AUS overview]]
* [[Software_Update:Nightly_update_infrastructure|updates for nightlies]]

== More things not covered here yet ==
* [http://wiki.mozilla.org/index.php?title=Calendar:Sunbird_Updates auto update] and the according {{bug|381420}}
* [http://wiki.mozilla.org/Build:CommunitySelfHelp talkback changes] required for a version change

------------------------------------------------------

= '''Release Process Old Page''' =
keeping as reference for now - probaly remove when reworking is done.
------------------------------------------------------

== Create a branch ==
1. Create a branch from the branch you are releasing from this creates a ${PRODUCT_TAG}_BRANCH from the MOZILLA_1_8_BRANCH, you also need to note the time this was done on a page like [[Calendar:Release:Sunbird_0.5]].
<pre>
cvs rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH mozilla
Note time this is done: May 22, 21:37 CDT</pre>
2. Test that the branch was properly created by checking out from the branch.
<pre> cvs co -r ${BRANCH_TAG}_BRANCH mozilla/calendar </pre>

== Change the Version Number ==
* You check out the branch you just created - use standard "check out code from mozilla cvs method", just substitute in the new branch for your branch parameter
* On this branch, you change the follwing:
* calendar/sunbird/app/module.ver
* calendar/sunbird/config/version.txt
* Then you:
<pre>cvs -d ${CVSROOT} co -r ${PRODUCT_TAG}_BRANCH\
mozilla/calendar/sunbird/app/module.ver mozilla/calendar/sunbird/config/version.txt
</pre>

==Create a minibranch==
<pre>
cvs tag -b ${PRODUCT_TAG}_MINIBRANCH calendar/sunbird/app/module.ver \
calendar/sunbird/config/version.txt
cvs up -r ${PRODUCT_TAG}_MINIBRANCH calendar/sunbird/app/module.ver \
calendar/sunbird/config/version.txt
cvs ci -m"bumping version number on calendar/sunbird on minibranch only"
</pre>

* remove firefox stuff from calendar/lightning/install.rdf

== Tag the release ==
* run "date" before you start and use this as date stamp.
* the date should be in UTC and have this format: "yyyy-mm-dd hh:mm +0000"
* You need to use an RC here in case we have RC builds that way RCs will move forward to the release (you can have multiple RC's but there is only one release) so ${RC} becomes 1 for the first attempt to release 0.5
<pre>
screen
cd .. (one up from mozilla)
mkdir -p tags/${PRODUCT_TAG}_RC${RC}
cd tags && ln -s ${PRODUCT_TAG}_RC${RC} ${PRODUCT_TAG}_RELEASE && \
ln -s ${PRODUCT_TAG}_RC${RC} ${PRODUCT_TAG}_RELEASE
</pre>
* Next, check out mozilla/client.mk and any <something>/config/mozconfig files you need with statements like this:
<pre>
cvs co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
mozilla/client.mk
becomes: cvs co -r ${PRODUCT_TAG}_BRANCH -D "2007-05-23 04:00 +0000" mozilla/client.mk
</pre>
* Next, you follow these steps:
<pre>
# pull version files from the version bump minibranch
cvs up -r ${PRODUCT_TAG}_MINIBRANCH ${APP}/app/module.ver \
${APP}/config/version.txt config/milestone.txt

# Create the tag.
cvs tag ${PRODUCT_TAG}_RELEASE 2>&1 | tee ../${PRODUCT_TAG}_RELEASE.log
# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RELEASE.log

# Create the RC tag.
cvs tag ${PRODUCT_TAG}_RC${RC} 2>&1 | tee ../${BRANCH_TAG}_RC${RC}.log
# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RC${RC}.log

# Create a minibranch for the pull scripts so we can change them without
# changing anything on the original branch.
cvs tag -b ${PRODUCT_TAG}_MINIBRANCH client.mk

# Update client.mk to the minibranch you just created.
cvs up -r ${PRODUCT_TAG}_MINIBRANCH client.mk

# Add the new product tag to the client.mk - need to replace the current branch ID
sed "s/${MOZILLA_1_8_BRANCH}/${PRODUCT_TAG}_RELEASE/g" client.mk > client.mk.tmp
mv client.mk.tmp client.mk

# Verify that client.mk only has the changes you expect
cvs diff -u client.mk
# Verify that client.mk has its sticky tag set properly.
cvs status client.mk
cvs commit -m "For $PRODUCT $VERSION, redirect client.mk onto the ${PRODUCT_TAG}_RELEASE tag." client.mk

# Move the release tag onto the modified version of the pull scripts.
# Note that you may have to wait to gain a lock, that is normal.
cvs tag -F ${PRODUCT_TAG}_RELEASE client.mk
cvs tag -F ${PRODUCT_TAG}_RC${RC} client.mk
</pre>

=== Tag Talkback===
* '''NOTE:''' to do this, you need access to talkback, currently only lilmatt has that access on our team.
<pre>
# Create the mofo tag directory.
cd ~cltbld/tags/${PRODUCT_TAG}_RC${RC}
mkdir mofo/
cd mofo/

# Branch Talkback like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT}/mofo rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH mofo

# Check out the talkback files from the branch you want to tag.
cvs -d :ext:cltbld@cvs.mozilla.org:/mofo co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
talkback/fullsoft 2>&1 | tee checkout-output.log

# Create the tag.
cd talkback/fullsoft/
cvs tag ${PRODUCT_TAG}_RELEASE 2>&1 | tee ../${PRODUCT_TAG}_RELEASE.log

# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RELEASE.log
</pre>

=== Tag L10N ===
* Note that you will need L10N access to do this
<pre>
# Create the l10n tag directory.
cd ~cltbld/tags/${PRODUCT_TAG}_RELEASE
mkdir l10n/
cd l10n/

# Branch Locales like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT}/l10n rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH l10n

# Grab list of shipped locales
LOCALES=`awk '{print $1}' < ../cvsroot/mozilla/calendar/locales/shipped-locales`

# Check out the l10n files from the branch you want to tag.
(for l in $LOCALES
do
cvs -d ${CVSROOT}/l10n co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
l10n/${l}
done) 2>&1 | tee checkout-output.log

cd l10n/
</pre>

Use lilmatt's magic L10N script to compile Lightning into Locales. You can find the script in {{bug|352546}}. We will check it into the main tree somewhere (suggested name: m/c/lilmattsmagicbuildtricks). You need to update the .dtd and .properties filenames for the current release.

==Push tag forward on updated l10n files==
In the <code>l10n</code> directory where you originally tagged l10n...
cvs up -r SUNBIRD_0_5_BRANCH
cvs tag -F SUNBIRD_0_5_RELEASE

Calendar:HowToRelease

2008-03-04T12:19:00Z

Ause: /* '''Release Process''' */

= '''Release Process''' =
== Overview ==
This is a short summery of steps required to do a release of Sunbird/Lightning. For simplicity, these steps are expected to be executed in the order mentioned here. Each step will have a more detailed section below.

To prepare for a release:
* Create a branch in mozilla repository
* Create a branch in l10n repository
* Change Tinderboxes to build form that branch
* Change the Version Number
* Create localized version of Lightning (to be done in the build - see [https://bugzilla.mozilla.org/show_bug.cgi?id=352546 Bug 352546])
* Tag files on the branch to make a RC if required

When the final RC gets approved:
* Tag files on the branch with a release tag
* Create Mac universal binaries (to be done in the build too?)
* Move stuff around on stage server

== Create a branch ==
NOTES:
* ${PRODUCT_TAG} is the header for the BRANCH - for sunbird 0.7 this will de SUNBIRD_0_7, other releases should follow the same convention
* ${BRANCH_TAG} is made by appending _BRANCH to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_BRANCH
* ${RC_TAG} is made by appending _RC to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_RC
* ${RELEASE_TAG} is made by appending _RELEASE to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_RELEASE
* If you intend to see changes made for this release, esp. the fixes, in any later release, keep in mind to also commit them to the regular development branch, e.g.
tools/cross-commit --trunk --moz18 --branch=${PRODUCT_TAG}_BRANCH ...

=== mozilla cvs repository ===
1. Create a branch from the branch you are releasing from. This creates a ${PRODUCT_TAG}_BRANCH from the MOZILLA_1_8_BRANCH,
<pre>
cvs co -r MOZILLA_1_8_BRANCH mozilla/client.mk

make -f mozilla/client.mk checkout MOZ_CO_PROJECT="mail,calendar" MOZ_CO_MODULE="mozilla/tools/update-packaging"

cd mozilla

cvs tag -b ${PRODUCT_TAG}_BRANCH mozilla

</pre>
NOTE:
* Tagging the tree created with "make checkout" just creates a branch on those files required. This to prefer to polluting all files with rtag if possible

2. Test that the branch was properly created by checking out from the branch.
<pre> cvs co -r ${BRANCH_TAG}_BRANCH mozilla </pre>

=== l10n cvs repository ===

* Note that you will need L10N access to do this
<pre>
# Branch Locales like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT_L10N} rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH l10n
</pre>

From now on, changes meant to apper in the release are done on this branch.

== Change Tinderboxes for Release ==

"tinderbox-config.pl" and the according "mozconfig" files have to be changed to let the tinderboxes pick up the release branch and do "release builds".

NOTES:
* be sure to make these changes on the cvs branch the desired tinderbox picks up. These are MOZILLA_1_8_BRANCH for regular tinderboxes and MOZILLA_1_8_BRANCH_l10n for the l10n tinderboxes.

The following sample shows the changes done for linux when switching back from "release mode" to "nightly".

TODO: place the changes done for 0.7 here

<pre>
Index: tinder-config.pl
===================================================================
RCS file: /cvsroot/mozilla/tools/tinderbox-configs/sunbird/linux/tinder-config.pl,v
retrieving revision 1.26.2.8
retrieving revision 1.26.2.9
diff -u -r1.26.2.8 -r1.26.2.9
--- tinder-config.pl 24 May 2007 16:56:07 -0000 1.26.2.8
+++ tinder-config.pl 28 Jun 2007 20:21:07 -0000 1.26.2.9
@@ -49,8 +49,8 @@
# Tests
$CleanProfile = 1;
$ResetHomeDirForTests = 1;
-$ProductName = "Sunbird";
-#$ProductName = 'Calendar';
+#$ProductName = "Sunbird";
+$ProductName = 'Calendar';
$VendorName = 'Mozilla';

#$RunMozillaTests = 1; # Allow turning off of all tests if needed.
@@ -166,13 +166,8 @@

$LocalizationVersionFile = 'calendar/sunbird/config/version.txt';

-#%WGetFiles = (
-# "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/latest-mozilla1.8/sunbird-%version%.en-US.linux-i686.tar.gz" =>
-# "/builds/tinderbox/Sb-Mozilla1.8-l10n/Linux_2.4.21-37.EL_Clobber/sunbird.tar.gz"
-# );
-
%WGetFiles = (
- "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/candidates/0.5rc1/sunbird-%version%.en-US.linux-i686.tar.gz" =>
+ "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/latest-mozilla1.8/sunbird-%version%.en-US.linux-i686.tar.gz" =>
"/builds/tinderbox/Sb-Mozilla1.8-l10n/Linux_2.4.21-37.EL_Clobber/sunbird.tar.gz"
);

@@ -190,8 +185,8 @@
$BuildTree = 'Mozilla1.8-l10n';

#$BuildName = '';
-#$BuildTag = 'MOZILLA_1_8_BRANCH';
-$BuildTag = 'SUNBIRD_0_5_RELEASE';
+$BuildTag = 'MOZILLA_1_8_BRANCH';
+#$BuildTag = 'SUNBIRD_0_5_RELEASE';
#$BuildConfigDir = 'mozilla/config';
#$Topsrcdir = 'mozilla';
</pre>

== Change the Version Number ==

* You check out the branch you just created - use standard "check out code from mozilla cvs method", just substitute in the new branch for your branch parameter
* On this branch, you change the follwing:
* calendar/sunbird/app/module.ver
* calendar/sunbird/config/version.txt
* Then you:
<pre>cvs -d ${CVSROOT} co -r ${PRODUCT_TAG}_BRANCH\
mozilla/calendar/sunbird/app/module.ver mozilla/calendar/sunbird/config/version.txt
</pre>

== Tag RC ==
At a specific point in time, when you feel it's right do
<pre>
cvs rtag -r ${PRODUCT_TAG}_BRANCH ${PRODUCT_TAG}_RCn mozilla
cvs rtag -r ${PRODUCT_TAG}_BRANCH ${PRODUCT_TAG}_RCn l10n
</pre>

of cause you can use something like "..._RCn" where "n" is the number of your release candidate.

== Create Mac universal binaries ==

Mac universal binaries are now created by the tinderbox.

== Pushing builds to the release tree ==
=== Sunbird ===
For the 0.7 release the required files were copied from the nightly directories and collected in a 0.7-candidates directory still in the nightly tree (flat structure, no renaming). Once all desired languages and platforms are there, a script exists to deliver them into the expected structure (platform/language) in the release tree and do the renaming.

TODO: provide de-personalized version of this script

TODO: provide usage example

TODO: make this script fix access rights and cretate MD5SUM files

=== Lightning ===

Lightning builds now create localized .xpi

== Providing updates for Sunbird ==
With the changes to the tinderboxe configuration (TODO: link to tb changes) also creation of update files (*.mar) gets enabled. While the complete updates are provided and uploaded by the tinderboxes, creating partial updates requires some manual work (see [[Software_Update:GeneratingSnippetsAndPartialsForReleases#Creating_updates |patcher2]]).

TODO: insert patcher2 config for sunbird

NOTE:
These update files can be tested manually as described in [[Software_Update:GeneratingSnippetsAndPartialsForReleases#How_Firefox.2FThunderbird_updates_are_tested]] .
Once the partial .mar are created and uploaded to the stage server, the according update information (snippets) need to be pushed to the AUS server.

helpfull links:
* [[Software_Update:GeneratingSnippetsAndPartialsForReleases| patcher2]]
* [[AUS|AUS overview]]
* [[Software_Update:Nightly_update_infrastructure|updates for nightlies]]

== More things not covered here yet ==
* [http://wiki.mozilla.org/index.php?title=Calendar:Sunbird_Updates auto update] and the according {{bug|381420}}
* [http://wiki.mozilla.org/Build:CommunitySelfHelp talkback changes] required for a version change

------------------------------------------------------

= '''Release Process Old Page''' =
keeping as reference for now - probaly remove when reworking is done.
------------------------------------------------------

== Create a branch ==
1. Create a branch from the branch you are releasing from this creates a ${PRODUCT_TAG}_BRANCH from the MOZILLA_1_8_BRANCH, you also need to note the time this was done on a page like [[Calendar:Release:Sunbird_0.5]].
<pre>
cvs rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH mozilla
Note time this is done: May 22, 21:37 CDT</pre>
2. Test that the branch was properly created by checking out from the branch.
<pre> cvs co -r ${BRANCH_TAG}_BRANCH mozilla/calendar </pre>

== Change the Version Number ==
* You check out the branch you just created - use standard "check out code from mozilla cvs method", just substitute in the new branch for your branch parameter
* On this branch, you change the follwing:
* calendar/sunbird/app/module.ver
* calendar/sunbird/config/version.txt
* Then you:
<pre>cvs -d ${CVSROOT} co -r ${PRODUCT_TAG}_BRANCH\
mozilla/calendar/sunbird/app/module.ver mozilla/calendar/sunbird/config/version.txt
</pre>

==Create a minibranch==
<pre>
cvs tag -b ${PRODUCT_TAG}_MINIBRANCH calendar/sunbird/app/module.ver \
calendar/sunbird/config/version.txt
cvs up -r ${PRODUCT_TAG}_MINIBRANCH calendar/sunbird/app/module.ver \
calendar/sunbird/config/version.txt
cvs ci -m"bumping version number on calendar/sunbird on minibranch only"
</pre>

* remove firefox stuff from calendar/lightning/install.rdf

== Tag the release ==
* run "date" before you start and use this as date stamp.
* the date should be in UTC and have this format: "yyyy-mm-dd hh:mm +0000"
* You need to use an RC here in case we have RC builds that way RCs will move forward to the release (you can have multiple RC's but there is only one release) so ${RC} becomes 1 for the first attempt to release 0.5
<pre>
screen
cd .. (one up from mozilla)
mkdir -p tags/${PRODUCT_TAG}_RC${RC}
cd tags && ln -s ${PRODUCT_TAG}_RC${RC} ${PRODUCT_TAG}_RELEASE && \
ln -s ${PRODUCT_TAG}_RC${RC} ${PRODUCT_TAG}_RELEASE
</pre>
* Next, check out mozilla/client.mk and any <something>/config/mozconfig files you need with statements like this:
<pre>
cvs co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
mozilla/client.mk
becomes: cvs co -r ${PRODUCT_TAG}_BRANCH -D "2007-05-23 04:00 +0000" mozilla/client.mk
</pre>
* Next, you follow these steps:
<pre>
# pull version files from the version bump minibranch
cvs up -r ${PRODUCT_TAG}_MINIBRANCH ${APP}/app/module.ver \
${APP}/config/version.txt config/milestone.txt

# Create the tag.
cvs tag ${PRODUCT_TAG}_RELEASE 2>&1 | tee ../${PRODUCT_TAG}_RELEASE.log
# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RELEASE.log

# Create the RC tag.
cvs tag ${PRODUCT_TAG}_RC${RC} 2>&1 | tee ../${BRANCH_TAG}_RC${RC}.log
# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RC${RC}.log

# Create a minibranch for the pull scripts so we can change them without
# changing anything on the original branch.
cvs tag -b ${PRODUCT_TAG}_MINIBRANCH client.mk

# Update client.mk to the minibranch you just created.
cvs up -r ${PRODUCT_TAG}_MINIBRANCH client.mk

# Add the new product tag to the client.mk - need to replace the current branch ID
sed "s/${MOZILLA_1_8_BRANCH}/${PRODUCT_TAG}_RELEASE/g" client.mk > client.mk.tmp
mv client.mk.tmp client.mk

# Verify that client.mk only has the changes you expect
cvs diff -u client.mk
# Verify that client.mk has its sticky tag set properly.
cvs status client.mk
cvs commit -m "For $PRODUCT $VERSION, redirect client.mk onto the ${PRODUCT_TAG}_RELEASE tag." client.mk

# Move the release tag onto the modified version of the pull scripts.
# Note that you may have to wait to gain a lock, that is normal.
cvs tag -F ${PRODUCT_TAG}_RELEASE client.mk
cvs tag -F ${PRODUCT_TAG}_RC${RC} client.mk
</pre>

=== Tag Talkback===
* '''NOTE:''' to do this, you need access to talkback, currently only lilmatt has that access on our team.
<pre>
# Create the mofo tag directory.
cd ~cltbld/tags/${PRODUCT_TAG}_RC${RC}
mkdir mofo/
cd mofo/

# Branch Talkback like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT}/mofo rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH mofo

# Check out the talkback files from the branch you want to tag.
cvs -d :ext:cltbld@cvs.mozilla.org:/mofo co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
talkback/fullsoft 2>&1 | tee checkout-output.log

# Create the tag.
cd talkback/fullsoft/
cvs tag ${PRODUCT_TAG}_RELEASE 2>&1 | tee ../${PRODUCT_TAG}_RELEASE.log

# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RELEASE.log
</pre>

=== Tag L10N ===
* Note that you will need L10N access to do this
<pre>
# Create the l10n tag directory.
cd ~cltbld/tags/${PRODUCT_TAG}_RELEASE
mkdir l10n/
cd l10n/

# Branch Locales like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT}/l10n rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH l10n

# Grab list of shipped locales
LOCALES=`awk '{print $1}' < ../cvsroot/mozilla/calendar/locales/shipped-locales`

# Check out the l10n files from the branch you want to tag.
(for l in $LOCALES
do
cvs -d ${CVSROOT}/l10n co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
l10n/${l}
done) 2>&1 | tee checkout-output.log

cd l10n/
</pre>

Use lilmatt's magic L10N script to compile Lightning into Locales. You can find the script in {{bug|352546}}. We will check it into the main tree somewhere (suggested name: m/c/lilmattsmagicbuildtricks). You need to update the .dtd and .properties filenames for the current release.

==Push tag forward on updated l10n files==
In the <code>l10n</code> directory where you originally tagged l10n...
cvs up -r SUNBIRD_0_5_BRANCH
cvs tag -F SUNBIRD_0_5_RELEASE

Calendar:HowToRelease

2007-10-31T12:59:37Z

Ause: /* '''Release Process''' */

= '''Release Process''' =
== Overview ==
This is a short summery of steps required to do a release of Sunbird/Lightning. For simplicity, these steps are expected to be executed in the order mentioned here. Each step will have a more detailed section below.

To prepare for a release:
* Create a branch in mozilla repository
* Create a branch in l10n repository
* Change Tinderboxes to build form that branch
* Change the Version Number
* Create localized version of Lightning (to be done in the build - see [https://bugzilla.mozilla.org/show_bug.cgi?id=352546 Bug 352546])
* Tag files on the branch to make a RC if required

When the final RC gets approved:
* Tag files on the branch with a release tag
* Create Mac universal binaries (to be done in the build too?)
* Move stuff around on stage server

== Create a branch ==
NOTES:
* ${PRODUCT_TAG} is the header for the BRANCH - for sunbird 0.7 this will de SUNBIRD_0_7, other releases should follow the same convention
* ${BRANCH_TAG} is made by appending _BRANCH to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_BRANCH
* ${RC_TAG} is made by appending _RC to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_RC
* ${RELEASE_TAG} is made by appending _RELEASE to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_RELEASE
* If you intend to see changes made for this release, esp. the fixes, in any later release, keep in mind to also commit them to the regular development branch, e.g.
tools/cross-commit --trunk --moz18 --branch=${PRODUCT_TAG}_BRANCH ...

=== mozilla cvs repository ===
1. Create a branch from the branch you are releasing from. This creates a ${PRODUCT_TAG}_BRANCH from the MOZILLA_1_8_BRANCH,
<pre>
cvs co -r MOZILLA_1_8_BRANCH mozilla/client.mk

make -f mozilla/client.mk checkout MOZ_CO_PROJECT="mail,calendar" MOZ_CO_MODULE="mozilla/tools/update-packaging"

cd mozilla

cvs tag -b ${PRODUCT_TAG}_BRANCH mozilla

</pre>
NOTE:
* Tagging the tree created with "make checkout" just creates a branch on those files required. This to prefer to polluting all files with rtag if possible

2. Test that the branch was properly created by checking out from the branch.
<pre> cvs co -r ${BRANCH_TAG}_BRANCH mozilla </pre>

=== l10n cvs repository ===

* Note that you will need L10N access to do this
<pre>
# Branch Locales like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT_L10N} rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH l10n
</pre>

From now on, changes meant to apper in the release are done on this branch.

== Change Tinderboxes for Release ==

"tinderbox-config.pl" and the according "mozconfig" files have to be changed to let the tinderboxes pick up the release branch and do "release builds".

NOTES:
* be sure to make these changes on the cvs branch the desired tinderbox picks up. These are MOZILLA_1_8_BRANCH for regular tinderboxes and MOZILLA_1_8_BRANCH_l10n for the l10n tinderboxes.

The following sample shows the changes done for linux when switching back from "release mode" to "nightly".

TODO: place the changes done for 0.7 here

<pre>
Index: tinder-config.pl
===================================================================
RCS file: /cvsroot/mozilla/tools/tinderbox-configs/sunbird/linux/tinder-config.pl,v
retrieving revision 1.26.2.8
retrieving revision 1.26.2.9
diff -u -r1.26.2.8 -r1.26.2.9
--- tinder-config.pl 24 May 2007 16:56:07 -0000 1.26.2.8
+++ tinder-config.pl 28 Jun 2007 20:21:07 -0000 1.26.2.9
@@ -49,8 +49,8 @@
# Tests
$CleanProfile = 1;
$ResetHomeDirForTests = 1;
-$ProductName = "Sunbird";
-#$ProductName = 'Calendar';
+#$ProductName = "Sunbird";
+$ProductName = 'Calendar';
$VendorName = 'Mozilla';

#$RunMozillaTests = 1; # Allow turning off of all tests if needed.
@@ -166,13 +166,8 @@

$LocalizationVersionFile = 'calendar/sunbird/config/version.txt';

-#%WGetFiles = (
-# "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/latest-mozilla1.8/sunbird-%version%.en-US.linux-i686.tar.gz" =>
-# "/builds/tinderbox/Sb-Mozilla1.8-l10n/Linux_2.4.21-37.EL_Clobber/sunbird.tar.gz"
-# );
-
%WGetFiles = (
- "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/candidates/0.5rc1/sunbird-%version%.en-US.linux-i686.tar.gz" =>
+ "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/latest-mozilla1.8/sunbird-%version%.en-US.linux-i686.tar.gz" =>
"/builds/tinderbox/Sb-Mozilla1.8-l10n/Linux_2.4.21-37.EL_Clobber/sunbird.tar.gz"
);

@@ -190,8 +185,8 @@
$BuildTree = 'Mozilla1.8-l10n';

#$BuildName = '';
-#$BuildTag = 'MOZILLA_1_8_BRANCH';
-$BuildTag = 'SUNBIRD_0_5_RELEASE';
+$BuildTag = 'MOZILLA_1_8_BRANCH';
+#$BuildTag = 'SUNBIRD_0_5_RELEASE';
#$BuildConfigDir = 'mozilla/config';
#$Topsrcdir = 'mozilla';
</pre>

== Change the Version Number ==

* You check out the branch you just created - use standard "check out code from mozilla cvs method", just substitute in the new branch for your branch parameter
* On this branch, you change the follwing:
* calendar/sunbird/app/module.ver
* calendar/sunbird/config/version.txt
* Then you:
<pre>cvs -d ${CVSROOT} co -r ${PRODUCT_TAG}_BRANCH\
mozilla/calendar/sunbird/app/module.ver mozilla/calendar/sunbird/config/version.txt
</pre>

== Create localized version of Lightning ==

TODO

== Tag RC ==
At a specific point in time, when you feel it's right do
<pre>
cvs rtag -r ${PRODUCT_TAG}_BRANCH ${PRODUCT_TAG}_RCn mozilla
cvs rtag -r ${PRODUCT_TAG}_BRANCH ${PRODUCT_TAG}_RCn l10n
</pre>

of cause you can use something like "..._RCn" where "n" is the number of your release candidate.

== Create Mac universal binaries ==

=== Mac Lightning Multi Platform XPIs ===
The Mac multi platform XPI has two <code>targetPlatform</code> tags in its <code>install.rdf</code>:
<pre>
<em:targetPlatform>Darwin_ppc-gcc3</em:targetPlatform>
<em:targetPlatform>Darwin_x86-gcc3</em:targetPlatform>
</pre>

and further on the XPI's directory structure is different. The <code>components</code> directory doesn't contain any native dylibs, but those are hosted in:
platform/Darwin_x86-gcc3/components/
libcalbasecomps.dylib
libstoragecomps.dylib
libwebdav.dylib
platform/Darwin_ppc-gcc3/components/
libcalbasecomps.dylib
libstoragecomps.dylib
libwebdav.dylib

== Pushing builds to the release tree ==
=== Sunbird ===
For the 0.7 release the required files were copied from the nightly directories and collected in a 0.7-candidates directory still in the nightly tree (flat structure, no renaming). Once all desired languages and platforms are there, a script exists to deliver them into the expected structure (platform/language) in the release tree and do the renaming.

TODO: provide de-personalized version of this script

TODO: provide usage example

TODO: make this script fix access rights and cretate MD5SUM files

=== Lightning ===
There is still running a bunch of scripts for localization (TODO: link to script) repackaging (wcap, universal binaries on mac) and renaming required that has to be done locally. Just the final results are uploaded.

Hopefully this changes for the next releases.

== Providing updates for Sunbird ==
With the changes to the tinderboxe configuration (TODO: link to tb changes) also creation of update files (*.mar) gets enabled. While the complete updates are provided and uploaded by the tinderboxes, creating partial updates requires some manual work (see [[Software_Update:GeneratingSnippetsAndPartialsForReleases#Creating_updates |patcher2]]).

TODO: insert patcher2 config for sunbird

NOTE:
These update files can be tested manually as described in [[Software_Update:GeneratingSnippetsAndPartialsForReleases#How_Firefox.2FThunderbird_updates_are_tested]] .
Once the partial .mar are created and uploaded to the stage server, the according update information (snippets) need to be pushed to the AUS server.

helpfull links:
* [[Software_Update:GeneratingSnippetsAndPartialsForReleases| patcher2]]
* [[AUS|AUS overview]]
* [[Software_Update:Nightly_update_infrastructure|updates for nightlies]]

== More things not covered here yet ==
* [http://wiki.mozilla.org/index.php?title=Calendar:Sunbird_Updates auto update] and the according {{bug|381420}}
* [http://wiki.mozilla.org/Build:CommunitySelfHelp talkback changes] required for a version change

------------------------------------------------------

= '''Release Process Old Page''' =
keeping as reference for now - probaly remove when reworking is done.
------------------------------------------------------

== Create a branch ==
1. Create a branch from the branch you are releasing from this creates a ${PRODUCT_TAG}_BRANCH from the MOZILLA_1_8_BRANCH, you also need to note the time this was done on a page like [[Calendar:Release:Sunbird_0.5]].
<pre>
cvs rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH mozilla
Note time this is done: May 22, 21:37 CDT</pre>
2. Test that the branch was properly created by checking out from the branch.
<pre> cvs co -r ${BRANCH_TAG}_BRANCH mozilla/calendar </pre>

== Change the Version Number ==
* You check out the branch you just created - use standard "check out code from mozilla cvs method", just substitute in the new branch for your branch parameter
* On this branch, you change the follwing:
* calendar/sunbird/app/module.ver
* calendar/sunbird/config/version.txt
* Then you:
<pre>cvs -d ${CVSROOT} co -r ${PRODUCT_TAG}_BRANCH\
mozilla/calendar/sunbird/app/module.ver mozilla/calendar/sunbird/config/version.txt
</pre>

==Create a minibranch==
<pre>
cvs tag -b ${PRODUCT_TAG}_MINIBRANCH calendar/sunbird/app/module.ver \
calendar/sunbird/config/version.txt
cvs up -r ${PRODUCT_TAG}_MINIBRANCH calendar/sunbird/app/module.ver \
calendar/sunbird/config/version.txt
cvs ci -m"bumping version number on calendar/sunbird on minibranch only"
</pre>

* remove firefox stuff from calendar/lightning/install.rdf

== Tag the release ==
* run "date" before you start and use this as date stamp.
* the date should be in UTC and have this format: "yyyy-mm-dd hh:mm +0000"
* You need to use an RC here in case we have RC builds that way RCs will move forward to the release (you can have multiple RC's but there is only one release) so ${RC} becomes 1 for the first attempt to release 0.5
<pre>
screen
cd .. (one up from mozilla)
mkdir -p tags/${PRODUCT_TAG}_RC${RC}
cd tags && ln -s ${PRODUCT_TAG}_RC${RC} ${PRODUCT_TAG}_RELEASE && \
ln -s ${PRODUCT_TAG}_RC${RC} ${PRODUCT_TAG}_RELEASE
</pre>
* Next, check out mozilla/client.mk and any <something>/config/mozconfig files you need with statements like this:
<pre>
cvs co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
mozilla/client.mk
becomes: cvs co -r ${PRODUCT_TAG}_BRANCH -D "2007-05-23 04:00 +0000" mozilla/client.mk
</pre>
* Next, you follow these steps:
<pre>
# pull version files from the version bump minibranch
cvs up -r ${PRODUCT_TAG}_MINIBRANCH ${APP}/app/module.ver \
${APP}/config/version.txt config/milestone.txt

# Create the tag.
cvs tag ${PRODUCT_TAG}_RELEASE 2>&1 | tee ../${PRODUCT_TAG}_RELEASE.log
# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RELEASE.log

# Create the RC tag.
cvs tag ${PRODUCT_TAG}_RC${RC} 2>&1 | tee ../${BRANCH_TAG}_RC${RC}.log
# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RC${RC}.log

# Create a minibranch for the pull scripts so we can change them without
# changing anything on the original branch.
cvs tag -b ${PRODUCT_TAG}_MINIBRANCH client.mk

# Update client.mk to the minibranch you just created.
cvs up -r ${PRODUCT_TAG}_MINIBRANCH client.mk

# Add the new product tag to the client.mk - need to replace the current branch ID
sed "s/${MOZILLA_1_8_BRANCH}/${PRODUCT_TAG}_RELEASE/g" client.mk > client.mk.tmp
mv client.mk.tmp client.mk

# Verify that client.mk only has the changes you expect
cvs diff -u client.mk
# Verify that client.mk has its sticky tag set properly.
cvs status client.mk
cvs commit -m "For $PRODUCT $VERSION, redirect client.mk onto the ${PRODUCT_TAG}_RELEASE tag." client.mk

# Move the release tag onto the modified version of the pull scripts.
# Note that you may have to wait to gain a lock, that is normal.
cvs tag -F ${PRODUCT_TAG}_RELEASE client.mk
cvs tag -F ${PRODUCT_TAG}_RC${RC} client.mk
</pre>

=== Tag Talkback===
* '''NOTE:''' to do this, you need access to talkback, currently only lilmatt has that access on our team.
<pre>
# Create the mofo tag directory.
cd ~cltbld/tags/${PRODUCT_TAG}_RC${RC}
mkdir mofo/
cd mofo/

# Branch Talkback like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT}/mofo rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH mofo

# Check out the talkback files from the branch you want to tag.
cvs -d :ext:cltbld@cvs.mozilla.org:/mofo co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
talkback/fullsoft 2>&1 | tee checkout-output.log

# Create the tag.
cd talkback/fullsoft/
cvs tag ${PRODUCT_TAG}_RELEASE 2>&1 | tee ../${PRODUCT_TAG}_RELEASE.log

# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RELEASE.log
</pre>

=== Tag L10N ===
* Note that you will need L10N access to do this
<pre>
# Create the l10n tag directory.
cd ~cltbld/tags/${PRODUCT_TAG}_RELEASE
mkdir l10n/
cd l10n/

# Branch Locales like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT}/l10n rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH l10n

# Grab list of shipped locales
LOCALES=`awk '{print $1}' < ../cvsroot/mozilla/calendar/locales/shipped-locales`

# Check out the l10n files from the branch you want to tag.
(for l in $LOCALES
do
cvs -d ${CVSROOT}/l10n co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
l10n/${l}
done) 2>&1 | tee checkout-output.log

cd l10n/
</pre>

Use lilmatt's magic L10N script to compile Lightning into Locales. You can find the script in {{bug|352546}}. We will check it into the main tree somewhere (suggested name: m/c/lilmattsmagicbuildtricks). You need to update the .dtd and .properties filenames for the current release.

==Push tag forward on updated l10n files==
In the <code>l10n</code> directory where you originally tagged l10n...
cvs up -r SUNBIRD_0_5_BRANCH
cvs tag -F SUNBIRD_0_5_RELEASE

Calendar:HowToRelease

2007-10-16T10:17:33Z

Ause: /* Change Tinderboxes for Release */

= '''Release Process''' =
== Overview ==
This is a short summery of steps required to do a release of Sunbird/Lightning. For simplicity, these steps are expected to be executed in the order mentioned here. Each step will have a more detailed section below.

To prepare for a release:
* Create a branch in mozilla repository
* Create a branch in l10n repository
* Change Tinderboxes to build form that branch
* Change the Version Number
* Create localized version of Lightning (to be done in the build - see [https://bugzilla.mozilla.org/show_bug.cgi?id=352546 Bug 352546])
* Tag files on the branch to make a RC if required

When the final RC gets approved:
* Tag files on the branch with a release tag
* Create Mac universal binaries (to be done in the build too?)
* Move stuff around on stage server

== Create a branch ==
NOTES:
* ${PRODUCT_TAG} is the header for the BRANCH - for sunbird 0.7 this will de SUNBIRD_0_7, other releases should follow the same convention
* ${BRANCH_TAG} is made by appending _BRANCH to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_BRANCH
* ${RC_TAG} is made by appending _RC to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_RC
* ${RELEASE_TAG} is made by appending _RELEASE to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_RELEASE
* If you intend to see changes made for this release, esp. the fixes, in any later release, keep in mind to also commit them to the regular development branch, e.g.
tools/cross-commit --trunk --moz18 --branch=${PRODUCT_TAG}_BRANCH ...

=== mozilla cvs repository ===
1. Create a branch from the branch you are releasing from. This creates a ${PRODUCT_TAG}_BRANCH from the MOZILLA_1_8_BRANCH,
<pre>
cvs co -r MOZILLA_1_8_BRANCH mozilla/client.mk

make -f mozilla/client.mk checkout MOZ_CO_PROJECT="mail,calendar" MOZ_CO_MODULE="mozilla/tools/update-packaging"

cd mozilla

cvs tag -b ${PRODUCT_TAG}_BRANCH mozilla

</pre>
NOTE:
* Tagging the tree created with "make checkout" just creates a branch on those files required. This to prefer to polluting all files with rtag if possible

2. Test that the branch was properly created by checking out from the branch.
<pre> cvs co -r ${BRANCH_TAG}_BRANCH mozilla </pre>

=== l10n cvs repository ===

* Note that you will need L10N access to do this
<pre>
# Branch Locales like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT_L10N} rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH l10n
</pre>

From now on, changes meant to apper in the release are done on this branch.

== Change Tinderboxes for Release ==

"tinderbox-config.pl" and the according "mozconfig" files have to be changed to let the tinderboxes pick up the release branch and do "release builds".

NOTES:
* be sure to make these changes on the cvs branch the desired tinderbox picks up. These are MOZILLA_1_8_BRANCH for regular tinderboxes and MOZILLA_1_8_BRANCH_l10n for the l10n tinderboxes.

The following sample shows the changes done for linux when switching back from "release mode" to "nightly".

TODO: place the changes done for 0.7 here

<pre>
Index: tinder-config.pl
===================================================================
RCS file: /cvsroot/mozilla/tools/tinderbox-configs/sunbird/linux/tinder-config.pl,v
retrieving revision 1.26.2.8
retrieving revision 1.26.2.9
diff -u -r1.26.2.8 -r1.26.2.9
--- tinder-config.pl 24 May 2007 16:56:07 -0000 1.26.2.8
+++ tinder-config.pl 28 Jun 2007 20:21:07 -0000 1.26.2.9
@@ -49,8 +49,8 @@
# Tests
$CleanProfile = 1;
$ResetHomeDirForTests = 1;
-$ProductName = "Sunbird";
-#$ProductName = 'Calendar';
+#$ProductName = "Sunbird";
+$ProductName = 'Calendar';
$VendorName = 'Mozilla';

#$RunMozillaTests = 1; # Allow turning off of all tests if needed.
@@ -166,13 +166,8 @@

$LocalizationVersionFile = 'calendar/sunbird/config/version.txt';

-#%WGetFiles = (
-# "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/latest-mozilla1.8/sunbird-%version%.en-US.linux-i686.tar.gz" =>
-# "/builds/tinderbox/Sb-Mozilla1.8-l10n/Linux_2.4.21-37.EL_Clobber/sunbird.tar.gz"
-# );
-
%WGetFiles = (
- "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/candidates/0.5rc1/sunbird-%version%.en-US.linux-i686.tar.gz" =>
+ "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/latest-mozilla1.8/sunbird-%version%.en-US.linux-i686.tar.gz" =>
"/builds/tinderbox/Sb-Mozilla1.8-l10n/Linux_2.4.21-37.EL_Clobber/sunbird.tar.gz"
);

@@ -190,8 +185,8 @@
$BuildTree = 'Mozilla1.8-l10n';

#$BuildName = '';
-#$BuildTag = 'MOZILLA_1_8_BRANCH';
-$BuildTag = 'SUNBIRD_0_5_RELEASE';
+$BuildTag = 'MOZILLA_1_8_BRANCH';
+#$BuildTag = 'SUNBIRD_0_5_RELEASE';
#$BuildConfigDir = 'mozilla/config';
#$Topsrcdir = 'mozilla';
</pre>

== Change the Version Number ==

* You check out the branch you just created - use standard "check out code from mozilla cvs method", just substitute in the new branch for your branch parameter
* On this branch, you change the follwing:
* calendar/sunbird/app/module.ver
* calendar/sunbird/config/version.txt
* Then you:
<pre>cvs -d ${CVSROOT} co -r ${PRODUCT_TAG}_BRANCH\
mozilla/calendar/sunbird/app/module.ver mozilla/calendar/sunbird/config/version.txt
</pre>

== Create localized version of Lightning ==

TODO

== Tag RC ==
At a specific point in time, when you feel it's right do
<pre>
cvs rtag -r ${PRODUCT_TAG}_BRANCH ${PRODUCT_TAG}_RCn mozilla
cvs rtag -r ${PRODUCT_TAG}_BRANCH ${PRODUCT_TAG}_RCn l10n
</pre>

of cause you can use something like "..._RCn" where "n" is the number of your release candidate.

== Create Mac universal binaries ==

=== Mac Lightning Multi Platform XPIs ===
The Mac multi platform XPI has two <code>targetPlatform</code> tags in its <code>install.rdf</code>:
<pre>
<em:targetPlatform>Darwin_ppc-gcc3</em:targetPlatform>
<em:targetPlatform>Darwin_x86-gcc3</em:targetPlatform>
</pre>

and further on the XPI's directory structure is different. The <code>components</code> directory doesn't contain any native dylibs, but those are hosted in:
platform/Darwin_x86-gcc3/components/
libcalbasecomps.dylib
libstoragecomps.dylib
libwebdav.dylib
platform/Darwin_ppc-gcc3/components/
libcalbasecomps.dylib
libstoragecomps.dylib
libwebdav.dylib

== Move stuff around on stage server ==

TODO

== More things not covered here yet ==
* [http://wiki.mozilla.org/index.php?title=Calendar:Sunbird_Updates auto update] and the according {{bug|381420}}
* [http://wiki.mozilla.org/Build:CommunitySelfHelp talkback changes] required for a version change

------------------------------------------------------

= '''Release Process Old Page''' =
keeping as reference for now - probaly remove when reworking is done.
------------------------------------------------------

== Create a branch ==
1. Create a branch from the branch you are releasing from this creates a ${PRODUCT_TAG}_BRANCH from the MOZILLA_1_8_BRANCH, you also need to note the time this was done on a page like [[Calendar:Release:Sunbird_0.5]].
<pre>
cvs rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH mozilla
Note time this is done: May 22, 21:37 CDT</pre>
2. Test that the branch was properly created by checking out from the branch.
<pre> cvs co -r ${BRANCH_TAG}_BRANCH mozilla/calendar </pre>

== Change the Version Number ==
* You check out the branch you just created - use standard "check out code from mozilla cvs method", just substitute in the new branch for your branch parameter
* On this branch, you change the follwing:
* calendar/sunbird/app/module.ver
* calendar/sunbird/config/version.txt
* Then you:
<pre>cvs -d ${CVSROOT} co -r ${PRODUCT_TAG}_BRANCH\
mozilla/calendar/sunbird/app/module.ver mozilla/calendar/sunbird/config/version.txt
</pre>

==Create a minibranch==
<pre>
cvs tag -b ${PRODUCT_TAG}_MINIBRANCH calendar/sunbird/app/module.ver \
calendar/sunbird/config/version.txt
cvs up -r ${PRODUCT_TAG}_MINIBRANCH calendar/sunbird/app/module.ver \
calendar/sunbird/config/version.txt
cvs ci -m"bumping version number on calendar/sunbird on minibranch only"
</pre>

* remove firefox stuff from calendar/lightning/install.rdf

== Tag the release ==
* run "date" before you start and use this as date stamp.
* the date should be in UTC and have this format: "yyyy-mm-dd hh:mm +0000"
* You need to use an RC here in case we have RC builds that way RCs will move forward to the release (you can have multiple RC's but there is only one release) so ${RC} becomes 1 for the first attempt to release 0.5
<pre>
screen
cd .. (one up from mozilla)
mkdir -p tags/${PRODUCT_TAG}_RC${RC}
cd tags && ln -s ${PRODUCT_TAG}_RC${RC} ${PRODUCT_TAG}_RELEASE && \
ln -s ${PRODUCT_TAG}_RC${RC} ${PRODUCT_TAG}_RELEASE
</pre>
* Next, check out mozilla/client.mk and any <something>/config/mozconfig files you need with statements like this:
<pre>
cvs co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
mozilla/client.mk
becomes: cvs co -r ${PRODUCT_TAG}_BRANCH -D "2007-05-23 04:00 +0000" mozilla/client.mk
</pre>
* Next, you follow these steps:
<pre>
# pull version files from the version bump minibranch
cvs up -r ${PRODUCT_TAG}_MINIBRANCH ${APP}/app/module.ver \
${APP}/config/version.txt config/milestone.txt

# Create the tag.
cvs tag ${PRODUCT_TAG}_RELEASE 2>&1 | tee ../${PRODUCT_TAG}_RELEASE.log
# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RELEASE.log

# Create the RC tag.
cvs tag ${PRODUCT_TAG}_RC${RC} 2>&1 | tee ../${BRANCH_TAG}_RC${RC}.log
# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RC${RC}.log

# Create a minibranch for the pull scripts so we can change them without
# changing anything on the original branch.
cvs tag -b ${PRODUCT_TAG}_MINIBRANCH client.mk

# Update client.mk to the minibranch you just created.
cvs up -r ${PRODUCT_TAG}_MINIBRANCH client.mk

# Add the new product tag to the client.mk - need to replace the current branch ID
sed "s/${MOZILLA_1_8_BRANCH}/${PRODUCT_TAG}_RELEASE/g" client.mk > client.mk.tmp
mv client.mk.tmp client.mk

# Verify that client.mk only has the changes you expect
cvs diff -u client.mk
# Verify that client.mk has its sticky tag set properly.
cvs status client.mk
cvs commit -m "For $PRODUCT $VERSION, redirect client.mk onto the ${PRODUCT_TAG}_RELEASE tag." client.mk

# Move the release tag onto the modified version of the pull scripts.
# Note that you may have to wait to gain a lock, that is normal.
cvs tag -F ${PRODUCT_TAG}_RELEASE client.mk
cvs tag -F ${PRODUCT_TAG}_RC${RC} client.mk
</pre>

=== Tag Talkback===
* '''NOTE:''' to do this, you need access to talkback, currently only lilmatt has that access on our team.
<pre>
# Create the mofo tag directory.
cd ~cltbld/tags/${PRODUCT_TAG}_RC${RC}
mkdir mofo/
cd mofo/

# Branch Talkback like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT}/mofo rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH mofo

# Check out the talkback files from the branch you want to tag.
cvs -d :ext:cltbld@cvs.mozilla.org:/mofo co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
talkback/fullsoft 2>&1 | tee checkout-output.log

# Create the tag.
cd talkback/fullsoft/
cvs tag ${PRODUCT_TAG}_RELEASE 2>&1 | tee ../${PRODUCT_TAG}_RELEASE.log

# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RELEASE.log
</pre>

=== Tag L10N ===
* Note that you will need L10N access to do this
<pre>
# Create the l10n tag directory.
cd ~cltbld/tags/${PRODUCT_TAG}_RELEASE
mkdir l10n/
cd l10n/

# Branch Locales like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT}/l10n rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH l10n

# Grab list of shipped locales
LOCALES=`awk '{print $1}' < ../cvsroot/mozilla/calendar/locales/shipped-locales`

# Check out the l10n files from the branch you want to tag.
(for l in $LOCALES
do
cvs -d ${CVSROOT}/l10n co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
l10n/${l}
done) 2>&1 | tee checkout-output.log

cd l10n/
</pre>

Use lilmatt's magic L10N script to compile Lightning into Locales. You can find the script in {{bug|352546}}. We will check it into the main tree somewhere (suggested name: m/c/lilmattsmagicbuildtricks). You need to update the .dtd and .properties filenames for the current release.

==Push tag forward on updated l10n files==
In the <code>l10n</code> directory where you originally tagged l10n...
cvs up -r SUNBIRD_0_5_BRANCH
cvs tag -F SUNBIRD_0_5_RELEASE

Calendar:HowToRelease

2007-10-16T10:02:02Z

Ause: /* mozilla cvs repository */

= '''Release Process''' =
== Overview ==
This is a short summery of steps required to do a release of Sunbird/Lightning. For simplicity, these steps are expected to be executed in the order mentioned here. Each step will have a more detailed section below.

To prepare for a release:
* Create a branch in mozilla repository
* Create a branch in l10n repository
* Change Tinderboxes to build form that branch
* Change the Version Number
* Create localized version of Lightning (to be done in the build - see [https://bugzilla.mozilla.org/show_bug.cgi?id=352546 Bug 352546])
* Tag files on the branch to make a RC if required

When the final RC gets approved:
* Tag files on the branch with a release tag
* Create Mac universal binaries (to be done in the build too?)
* Move stuff around on stage server

== Create a branch ==
NOTES:
* ${PRODUCT_TAG} is the header for the BRANCH - for sunbird 0.7 this will de SUNBIRD_0_7, other releases should follow the same convention
* ${BRANCH_TAG} is made by appending _BRANCH to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_BRANCH
* ${RC_TAG} is made by appending _RC to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_RC
* ${RELEASE_TAG} is made by appending _RELEASE to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_RELEASE
* If you intend to see changes made for this release, esp. the fixes, in any later release, keep in mind to also commit them to the regular development branch, e.g.
tools/cross-commit --trunk --moz18 --branch=${PRODUCT_TAG}_BRANCH ...

=== mozilla cvs repository ===
1. Create a branch from the branch you are releasing from. This creates a ${PRODUCT_TAG}_BRANCH from the MOZILLA_1_8_BRANCH,
<pre>
cvs co -r MOZILLA_1_8_BRANCH mozilla/client.mk

make -f mozilla/client.mk checkout MOZ_CO_PROJECT="mail,calendar" MOZ_CO_MODULE="mozilla/tools/update-packaging"

cd mozilla

cvs tag -b ${PRODUCT_TAG}_BRANCH mozilla

</pre>
NOTE:
* Tagging the tree created with "make checkout" just creates a branch on those files required. This to prefer to polluting all files with rtag if possible

2. Test that the branch was properly created by checking out from the branch.
<pre> cvs co -r ${BRANCH_TAG}_BRANCH mozilla </pre>

=== l10n cvs repository ===

* Note that you will need L10N access to do this
<pre>
# Branch Locales like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT_L10N} rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH l10n
</pre>

From now on, changes meant to apper in the release are done on this branch.

== Change Tinderboxes for Release ==

"tinderbox-config.pl" files have to be changed to let the tinderboxes pick up the release branch. Also the destination on the stage server needs to be changed.

NOTES:
* be sure to make these changes on the cvs branch the desired tinderbox picks up.

The following sample shows the changes done for linux when switching back from "release mode" to "nightly".

<pre>
Index: tinder-config.pl
===================================================================
RCS file: /cvsroot/mozilla/tools/tinderbox-configs/sunbird/linux/tinder-config.pl,v
retrieving revision 1.26.2.8
retrieving revision 1.26.2.9
diff -u -r1.26.2.8 -r1.26.2.9
--- tinder-config.pl 24 May 2007 16:56:07 -0000 1.26.2.8
+++ tinder-config.pl 28 Jun 2007 20:21:07 -0000 1.26.2.9
@@ -49,8 +49,8 @@
# Tests
$CleanProfile = 1;
$ResetHomeDirForTests = 1;
-$ProductName = "Sunbird";
-#$ProductName = 'Calendar';
+#$ProductName = "Sunbird";
+$ProductName = 'Calendar';
$VendorName = 'Mozilla';

#$RunMozillaTests = 1; # Allow turning off of all tests if needed.
@@ -166,13 +166,8 @@

$LocalizationVersionFile = 'calendar/sunbird/config/version.txt';

-#%WGetFiles = (
-# "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/latest-mozilla1.8/sunbird-%version%.en-US.linux-i686.tar.gz" =>
-# "/builds/tinderbox/Sb-Mozilla1.8-l10n/Linux_2.4.21-37.EL_Clobber/sunbird.tar.gz"
-# );
-
%WGetFiles = (
- "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/candidates/0.5rc1/sunbird-%version%.en-US.linux-i686.tar.gz" =>
+ "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/latest-mozilla1.8/sunbird-%version%.en-US.linux-i686.tar.gz" =>
"/builds/tinderbox/Sb-Mozilla1.8-l10n/Linux_2.4.21-37.EL_Clobber/sunbird.tar.gz"
);

@@ -190,8 +185,8 @@
$BuildTree = 'Mozilla1.8-l10n';

#$BuildName = '';
-#$BuildTag = 'MOZILLA_1_8_BRANCH';
-$BuildTag = 'SUNBIRD_0_5_RELEASE';
+$BuildTag = 'MOZILLA_1_8_BRANCH';
+#$BuildTag = 'SUNBIRD_0_5_RELEASE';
#$BuildConfigDir = 'mozilla/config';
#$Topsrcdir = 'mozilla';
</pre>

== Change the Version Number ==

* You check out the branch you just created - use standard "check out code from mozilla cvs method", just substitute in the new branch for your branch parameter
* On this branch, you change the follwing:
* calendar/sunbird/app/module.ver
* calendar/sunbird/config/version.txt
* Then you:
<pre>cvs -d ${CVSROOT} co -r ${PRODUCT_TAG}_BRANCH\
mozilla/calendar/sunbird/app/module.ver mozilla/calendar/sunbird/config/version.txt
</pre>

== Create localized version of Lightning ==

TODO

== Tag RC ==
At a specific point in time, when you feel it's right do
<pre>
cvs rtag -r ${PRODUCT_TAG}_BRANCH ${PRODUCT_TAG}_RCn mozilla
cvs rtag -r ${PRODUCT_TAG}_BRANCH ${PRODUCT_TAG}_RCn l10n
</pre>

of cause you can use something like "..._RCn" where "n" is the number of your release candidate.

== Create Mac universal binaries ==

=== Mac Lightning Multi Platform XPIs ===
The Mac multi platform XPI has two <code>targetPlatform</code> tags in its <code>install.rdf</code>:
<pre>
<em:targetPlatform>Darwin_ppc-gcc3</em:targetPlatform>
<em:targetPlatform>Darwin_x86-gcc3</em:targetPlatform>
</pre>

and further on the XPI's directory structure is different. The <code>components</code> directory doesn't contain any native dylibs, but those are hosted in:
platform/Darwin_x86-gcc3/components/
libcalbasecomps.dylib
libstoragecomps.dylib
libwebdav.dylib
platform/Darwin_ppc-gcc3/components/
libcalbasecomps.dylib
libstoragecomps.dylib
libwebdav.dylib

== Move stuff around on stage server ==

TODO

== More things not covered here yet ==
* [http://wiki.mozilla.org/index.php?title=Calendar:Sunbird_Updates auto update] and the according {{bug|381420}}
* [http://wiki.mozilla.org/Build:CommunitySelfHelp talkback changes] required for a version change

------------------------------------------------------

= '''Release Process Old Page''' =
keeping as reference for now - probaly remove when reworking is done.
------------------------------------------------------

== Create a branch ==
1. Create a branch from the branch you are releasing from this creates a ${PRODUCT_TAG}_BRANCH from the MOZILLA_1_8_BRANCH, you also need to note the time this was done on a page like [[Calendar:Release:Sunbird_0.5]].
<pre>
cvs rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH mozilla
Note time this is done: May 22, 21:37 CDT</pre>
2. Test that the branch was properly created by checking out from the branch.
<pre> cvs co -r ${BRANCH_TAG}_BRANCH mozilla/calendar </pre>

== Change the Version Number ==
* You check out the branch you just created - use standard "check out code from mozilla cvs method", just substitute in the new branch for your branch parameter
* On this branch, you change the follwing:
* calendar/sunbird/app/module.ver
* calendar/sunbird/config/version.txt
* Then you:
<pre>cvs -d ${CVSROOT} co -r ${PRODUCT_TAG}_BRANCH\
mozilla/calendar/sunbird/app/module.ver mozilla/calendar/sunbird/config/version.txt
</pre>

==Create a minibranch==
<pre>
cvs tag -b ${PRODUCT_TAG}_MINIBRANCH calendar/sunbird/app/module.ver \
calendar/sunbird/config/version.txt
cvs up -r ${PRODUCT_TAG}_MINIBRANCH calendar/sunbird/app/module.ver \
calendar/sunbird/config/version.txt
cvs ci -m"bumping version number on calendar/sunbird on minibranch only"
</pre>

* remove firefox stuff from calendar/lightning/install.rdf

== Tag the release ==
* run "date" before you start and use this as date stamp.
* the date should be in UTC and have this format: "yyyy-mm-dd hh:mm +0000"
* You need to use an RC here in case we have RC builds that way RCs will move forward to the release (you can have multiple RC's but there is only one release) so ${RC} becomes 1 for the first attempt to release 0.5
<pre>
screen
cd .. (one up from mozilla)
mkdir -p tags/${PRODUCT_TAG}_RC${RC}
cd tags && ln -s ${PRODUCT_TAG}_RC${RC} ${PRODUCT_TAG}_RELEASE && \
ln -s ${PRODUCT_TAG}_RC${RC} ${PRODUCT_TAG}_RELEASE
</pre>
* Next, check out mozilla/client.mk and any <something>/config/mozconfig files you need with statements like this:
<pre>
cvs co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
mozilla/client.mk
becomes: cvs co -r ${PRODUCT_TAG}_BRANCH -D "2007-05-23 04:00 +0000" mozilla/client.mk
</pre>
* Next, you follow these steps:
<pre>
# pull version files from the version bump minibranch
cvs up -r ${PRODUCT_TAG}_MINIBRANCH ${APP}/app/module.ver \
${APP}/config/version.txt config/milestone.txt

# Create the tag.
cvs tag ${PRODUCT_TAG}_RELEASE 2>&1 | tee ../${PRODUCT_TAG}_RELEASE.log
# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RELEASE.log

# Create the RC tag.
cvs tag ${PRODUCT_TAG}_RC${RC} 2>&1 | tee ../${BRANCH_TAG}_RC${RC}.log
# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RC${RC}.log

# Create a minibranch for the pull scripts so we can change them without
# changing anything on the original branch.
cvs tag -b ${PRODUCT_TAG}_MINIBRANCH client.mk

# Update client.mk to the minibranch you just created.
cvs up -r ${PRODUCT_TAG}_MINIBRANCH client.mk

# Add the new product tag to the client.mk - need to replace the current branch ID
sed "s/${MOZILLA_1_8_BRANCH}/${PRODUCT_TAG}_RELEASE/g" client.mk > client.mk.tmp
mv client.mk.tmp client.mk

# Verify that client.mk only has the changes you expect
cvs diff -u client.mk
# Verify that client.mk has its sticky tag set properly.
cvs status client.mk
cvs commit -m "For $PRODUCT $VERSION, redirect client.mk onto the ${PRODUCT_TAG}_RELEASE tag." client.mk

# Move the release tag onto the modified version of the pull scripts.
# Note that you may have to wait to gain a lock, that is normal.
cvs tag -F ${PRODUCT_TAG}_RELEASE client.mk
cvs tag -F ${PRODUCT_TAG}_RC${RC} client.mk
</pre>

=== Tag Talkback===
* '''NOTE:''' to do this, you need access to talkback, currently only lilmatt has that access on our team.
<pre>
# Create the mofo tag directory.
cd ~cltbld/tags/${PRODUCT_TAG}_RC${RC}
mkdir mofo/
cd mofo/

# Branch Talkback like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT}/mofo rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH mofo

# Check out the talkback files from the branch you want to tag.
cvs -d :ext:cltbld@cvs.mozilla.org:/mofo co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
talkback/fullsoft 2>&1 | tee checkout-output.log

# Create the tag.
cd talkback/fullsoft/
cvs tag ${PRODUCT_TAG}_RELEASE 2>&1 | tee ../${PRODUCT_TAG}_RELEASE.log

# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RELEASE.log
</pre>

=== Tag L10N ===
* Note that you will need L10N access to do this
<pre>
# Create the l10n tag directory.
cd ~cltbld/tags/${PRODUCT_TAG}_RELEASE
mkdir l10n/
cd l10n/

# Branch Locales like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT}/l10n rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH l10n

# Grab list of shipped locales
LOCALES=`awk '{print $1}' < ../cvsroot/mozilla/calendar/locales/shipped-locales`

# Check out the l10n files from the branch you want to tag.
(for l in $LOCALES
do
cvs -d ${CVSROOT}/l10n co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
l10n/${l}
done) 2>&1 | tee checkout-output.log

cd l10n/
</pre>

Use lilmatt's magic L10N script to compile Lightning into Locales. You can find the script in {{bug|352546}}. We will check it into the main tree somewhere (suggested name: m/c/lilmattsmagicbuildtricks). You need to update the .dtd and .properties filenames for the current release.

==Push tag forward on updated l10n files==
In the <code>l10n</code> directory where you originally tagged l10n...
cvs up -r SUNBIRD_0_5_BRANCH
cvs tag -F SUNBIRD_0_5_RELEASE

Calendar:HowToRelease

2007-08-31T15:03:36Z

Ause: /* '''Release Process''' */

= '''Release Process''' =
== Overview ==
This is a short summery of steps required to do a release of Sunbird/Lightning. For simplicity, these steps are expected to be executed in the order mentioned here. Each step will have a more detailed section below.

To prepare for a release:
* Create a branch in mozilla repository
* Create a branch in l10n repository
* Change Tinderboxes to build form that branch
* Change the Version Number
* Create localized version of Lightning (to be done in the build - see Bug 352546)
* Tag files on the branch to make a RC if required

When the final RC gets approved:
* Tag files on the branch with a release tag
* Create Mac universal binaries (to be done in the build too?)
* Move stuff around on stage server

== Create a branch ==
NOTES:
* If you intend to see changes made for this release, esp. the fixes, in any later release, keep in mind to also commit them to the regular development branch.
* ${PRODUCT_TAG} is the header for the BRANCH - for sunbird 0.7 this will de SUNBIRD_0_7, other releases should follow the same convention
* ${BRANCH_TAG} is made by appending _BRANCH to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_BRANCH
* ${RC_TAG} is made by appending _RC to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_RC
* ${RELEASE_TAG} is made by appending _RELEASE to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_RELEASE

=== mozilla cvs repository ===
1. Create a branch from the branch you are releasing from. This creates a ${PRODUCT_TAG}_BRANCH from the MOZILLA_1_8_BRANCH,
<pre>
cvs rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH mozilla
</pre>
2. Test that the branch was properly created by checking out from the branch.
<pre> cvs co -r ${BRANCH_TAG}_BRANCH mozilla/calendar </pre>

=== l10n cvs repository ===

* Note that you will need L10N access to do this
<pre>
# Branch Locales like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT}/l10n rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH l10n
</pre>

From now on, changes meant to apper in the release are done on this branch.

== Change Tinderboxes for Release ==

"tinderbox-config.pl" files have to be changed to let the tinderboxes pick up the release branch. Also the destination on the stage server needs to be changed.

NOTES:
* be sure to make these changes on the cvs branch the desired tinderbox picks up.

The following sample shows the changes done for linux when switching back from "release mode" to "nightly".

<pre>
Index: tinder-config.pl
===================================================================
RCS file: /cvsroot/mozilla/tools/tinderbox-configs/sunbird/linux/tinder-config.pl,v
retrieving revision 1.26.2.8
retrieving revision 1.26.2.9
diff -u -r1.26.2.8 -r1.26.2.9
--- tinder-config.pl 24 May 2007 16:56:07 -0000 1.26.2.8
+++ tinder-config.pl 28 Jun 2007 20:21:07 -0000 1.26.2.9
@@ -49,8 +49,8 @@
# Tests
$CleanProfile = 1;
$ResetHomeDirForTests = 1;
-$ProductName = "Sunbird";
-#$ProductName = 'Calendar';
+#$ProductName = "Sunbird";
+$ProductName = 'Calendar';
$VendorName = 'Mozilla';

#$RunMozillaTests = 1; # Allow turning off of all tests if needed.
@@ -166,13 +166,8 @@

$LocalizationVersionFile = 'calendar/sunbird/config/version.txt';

-#%WGetFiles = (
-# "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/latest-mozilla1.8/sunbird-%version%.en-US.linux-i686.tar.gz" =>
-# "/builds/tinderbox/Sb-Mozilla1.8-l10n/Linux_2.4.21-37.EL_Clobber/sunbird.tar.gz"
-# );
-
%WGetFiles = (
- "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/candidates/0.5rc1/sunbird-%version%.en-US.linux-i686.tar.gz" =>
+ "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/latest-mozilla1.8/sunbird-%version%.en-US.linux-i686.tar.gz" =>
"/builds/tinderbox/Sb-Mozilla1.8-l10n/Linux_2.4.21-37.EL_Clobber/sunbird.tar.gz"
);

@@ -190,8 +185,8 @@
$BuildTree = 'Mozilla1.8-l10n';

#$BuildName = '';
-#$BuildTag = 'MOZILLA_1_8_BRANCH';
-$BuildTag = 'SUNBIRD_0_5_RELEASE';
+$BuildTag = 'MOZILLA_1_8_BRANCH';
+#$BuildTag = 'SUNBIRD_0_5_RELEASE';
#$BuildConfigDir = 'mozilla/config';
#$Topsrcdir = 'mozilla';
</pre>

== Change the Version Number ==

* You check out the branch you just created - use standard "check out code from mozilla cvs method", just substitute in the new branch for your branch parameter
* On this branch, you change the follwing:
* calendar/sunbird/app/module.ver
* calendar/sunbird/config/version.txt
* Then you:
<pre>cvs -d ${CVSROOT} co -r ${PRODUCT_TAG}_BRANCH\
mozilla/calendar/sunbird/app/module.ver mozilla/calendar/sunbird/config/version.txt
</pre>

== Create localized version of Lightning ==

== Tag RC ==
At a specific point in time, when you feel it's right do
<pre>
cvs rtag -r ${PRODUCT_TAG}_BRANCH ${PRODUCT_TAG}_RC mozilla
cvs rtag -r ${PRODUCT_TAG}_BRANCH ${PRODUCT_TAG}_RC l10n
</pre>

of cause you can use something like "..._RCn" where "n" is the number of your release candidate.

== Tag Release ==

Probably the best way to do it is to add the release tag to an already existing RC tag. Make sure to use the latest RC tag...

Could look like this:

<pre>
cvs rtag -r ${PRODUCT_TAG}_RC ${PRODUCT_TAG}_RELEASE mozilla
cvs rtag -r ${PRODUCT_TAG}_RC ${PRODUCT_TAG}_RELEASE l10n
</pre>

== Create Mac universal binaries ==

TODO

== Move stuff around on stage server ==

TODO

== More things not covered here yet ==
* [http://www.examhttp://wiki.mozilla.org/index.php?title=Calendar:Sunbird_Updates&action=editple.com auto update] and the according [https://bugzilla.mozilla.org/show_bug.cgi?id=381420 Bug 381420]
* [http://wiki.mozilla.org/Build:CommunitySelfHelp talkback changes] required for a version change

------------------------------------------------------

= '''Release Process Old Page''' =
keeping as reference for now - probaly remove when reworking is done.
------------------------------------------------------

== Create a branch ==
1. Create a branch from the branch you are releasing from this creates a ${PRODUCT_TAG}_BRANCH from the MOZILLA_1_8_BRANCH, you also need to note the time this was done on a page like [[Calendar:Release:Sunbird_0.5]].
<pre>
cvs rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH mozilla
Note time this is done: May 22, 21:37 CDT</pre>
2. Test that the branch was properly created by checking out from the branch.
<pre> cvs co -r ${BRANCH_TAG}_BRANCH mozilla/calendar </pre>

== Change the Version Number ==
* You check out the branch you just created - use standard "check out code from mozilla cvs method", just substitute in the new branch for your branch parameter
* On this branch, you change the follwing:
* calendar/sunbird/app/module.ver
* calendar/sunbird/config/version.txt
* Then you:
<pre>cvs -d ${CVSROOT} co -r ${PRODUCT_TAG}_BRANCH\
mozilla/calendar/sunbird/app/module.ver mozilla/calendar/sunbird/config/version.txt
</pre>

==Create a minibranch==
<pre>
cvs tag -b ${PRODUCT_TAG}_MINIBRANCH calendar/sunbird/app/module.ver \
calendar/sunbird/config/version.txt
cvs up -r ${PRODUCT_TAG}_MINIBRANCH calendar/sunbird/app/module.ver \
calendar/sunbird/config/version.txt
cvs ci -m"bumping version number on calendar/sunbird on minibranch only"
</pre>

* remove firefox stuff from calendar/lightning/install.rdf

== Tag the release ==
* run "date" before you start and use this as date stamp.
* the date should be in UTC and have this format: "yyyy-mm-dd hh:mm +0000"
* You need to use an RC here in case we have RC builds that way RCs will move forward to the release (you can have multiple RC's but there is only one release) so ${RC} becomes 1 for the first attempt to release 0.5
<pre>
screen
cd .. (one up from mozilla)
mkdir -p tags/${PRODUCT_TAG}_RC${RC}
cd tags && ln -s ${PRODUCT_TAG}_RC${RC} ${PRODUCT_TAG}_RELEASE && \
ln -s ${PRODUCT_TAG}_RC${RC} ${PRODUCT_TAG}_RELEASE
</pre>
* Next, check out mozilla/client.mk and any <something>/config/mozconfig files you need with statements like this:
<pre>
cvs co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
mozilla/client.mk
becomes: cvs co -r ${PRODUCT_TAG}_BRANCH -D "2007-05-23 04:00 +0000" mozilla/client.mk
</pre>
* Next, you follow these steps:
<pre>
# pull version files from the version bump minibranch
cvs up -r ${PRODUCT_TAG}_MINIBRANCH ${APP}/app/module.ver \
${APP}/config/version.txt config/milestone.txt

# Create the tag.
cvs tag ${PRODUCT_TAG}_RELEASE 2>&1 | tee ../${PRODUCT_TAG}_RELEASE.log
# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RELEASE.log

# Create the RC tag.
cvs tag ${PRODUCT_TAG}_RC${RC} 2>&1 | tee ../${BRANCH_TAG}_RC${RC}.log
# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RC${RC}.log

# Create a minibranch for the pull scripts so we can change them without
# changing anything on the original branch.
cvs tag -b ${PRODUCT_TAG}_MINIBRANCH client.mk

# Update client.mk to the minibranch you just created.
cvs up -r ${PRODUCT_TAG}_MINIBRANCH client.mk

# Add the new product tag to the client.mk - need to replace the current branch ID
sed "s/${MOZILLA_1_8_BRANCH}/${PRODUCT_TAG}_RELEASE/g" client.mk > client.mk.tmp
mv client.mk.tmp client.mk

# Verify that client.mk only has the changes you expect
cvs diff -u client.mk
# Verify that client.mk has its sticky tag set properly.
cvs status client.mk
cvs commit -m "For $PRODUCT $VERSION, redirect client.mk onto the ${PRODUCT_TAG}_RELEASE tag." client.mk

# Move the release tag onto the modified version of the pull scripts.
# Note that you may have to wait to gain a lock, that is normal.
cvs tag -F ${PRODUCT_TAG}_RELEASE client.mk
cvs tag -F ${PRODUCT_TAG}_RC${RC} client.mk
</pre>

=== Tag Talkback===
* '''NOTE:''' to do this, you need access to talkback, currently only lilmatt has that access on our team.
<pre>
# Create the mofo tag directory.
cd ~cltbld/tags/${PRODUCT_TAG}_RC${RC}
mkdir mofo/
cd mofo/

# Branch Talkback like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT}/mofo rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH mofo

# Check out the talkback files from the branch you want to tag.
cvs -d :ext:cltbld@cvs.mozilla.org:/mofo co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
talkback/fullsoft 2>&1 | tee checkout-output.log

# Create the tag.
cd talkback/fullsoft/
cvs tag ${PRODUCT_TAG}_RELEASE 2>&1 | tee ../${PRODUCT_TAG}_RELEASE.log

# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RELEASE.log
</pre>

=== Tag L10N ===
* Note that you will need L10N access to do this
<pre>
# Create the l10n tag directory.
cd ~cltbld/tags/${PRODUCT_TAG}_RELEASE
mkdir l10n/
cd l10n/

# Branch Locales like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT}/l10n rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH l10n

# Grab list of shipped locales
LOCALES=`awk '{print $1}' < ../cvsroot/mozilla/calendar/locales/shipped-locales`

# Check out the l10n files from the branch you want to tag.
(for l in $LOCALES
do
cvs -d ${CVSROOT}/l10n co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
l10n/${l}
done) 2>&1 | tee checkout-output.log

cd l10n/
</pre>

Use lilmatt's magic L10N script to compile Lightning into Locales. You can find the script in {{bug|352546}}. We will check it into the main tree somewhere (suggested name: m/c/lilmattsmagicbuildtricks). You need to update the .dtd and .properties filenames for the current release.

==Push tag forward on updated l10n files==
In the <code>l10n</code> directory where you originally tagged l10n...
cvs up -r SUNBIRD_0_5_BRANCH
cvs tag -F SUNBIRD_0_5_RELEASE

Calendar:HowToRelease

2007-08-02T14:15:32Z

Ause: /* Create a branch */

= '''Release Process''' =
== Overview ==
This is a short summery of steps required to do a release of Sunbird/Lightning. For simplicity, these steps are expected to be executed in the order mentioned here. Each step will have a more detailed section below.

To prepare for a release:
* Create a branch in mozilla repository
* Create a branch in l10n repository
* Change Tinderboxes to build form that branch
* Change the Version Number
* Create localized version of Lightning (to be done in the build - see Bug 352546)
* Tag files on the branch to make a RC if required

When the final RC gets approved:
* Tag files on the branch with a release tag
* Create Mac universal binaries (to be done in the build too?)
* Move stuff around on stage server

== Create a branch ==
NOTES:
* If you intend to see changes made for this release, esp. the fixes, in any later release, keep in mind to also commit them to the regular development branch.
* ${PRODUCT_TAG} is the header for the BRANCH - for sunbird 0.7 this will de SUNBIRD_0_7, other releases should follow the same convention
* ${BRANCH_TAG} is made by appending _BRANCH to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_BRANCH
* ${RC_TAG} is made by appending _RC to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_RC
* ${RELEASE_TAG} is made by appending _RELEASE to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_RELEASE

=== mozilla cvs repository ===
1. Create a branch from the branch you are releasing from. This creates a ${PRODUCT_TAG}_BRANCH from the MOZILLA_1_8_BRANCH,
<pre>
cvs rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH mozilla
</pre>
2. Test that the branch was properly created by checking out from the branch.
<pre> cvs co -r ${BRANCH_TAG}_BRANCH mozilla/calendar </pre>

=== l10n cvs repository ===

* Note that you will need L10N access to do this
<pre>
# Branch Locales like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT}/l10n rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH l10n
</pre>

From now on, changes meant to apper in the release are done on this branch.

== Change Tinderboxes for Release ==

"tinderbox-config.pl" files have to be changed to let the tinderboxes pick up the release branch. Also the destination on the stage server needs to be changed.

NOTES:
* be sure to make these changes on the cvs branch the desired tinderbox picks up.

The following sample shows the changes done for linux when switching back from "release mode" to "nightly".

<pre>
Index: tinder-config.pl
===================================================================
RCS file: /cvsroot/mozilla/tools/tinderbox-configs/sunbird/linux/tinder-config.pl,v
retrieving revision 1.26.2.8
retrieving revision 1.26.2.9
diff -u -r1.26.2.8 -r1.26.2.9
--- tinder-config.pl 24 May 2007 16:56:07 -0000 1.26.2.8
+++ tinder-config.pl 28 Jun 2007 20:21:07 -0000 1.26.2.9
@@ -49,8 +49,8 @@
# Tests
$CleanProfile = 1;
$ResetHomeDirForTests = 1;
-$ProductName = "Sunbird";
-#$ProductName = 'Calendar';
+#$ProductName = "Sunbird";
+$ProductName = 'Calendar';
$VendorName = 'Mozilla';

#$RunMozillaTests = 1; # Allow turning off of all tests if needed.
@@ -166,13 +166,8 @@

$LocalizationVersionFile = 'calendar/sunbird/config/version.txt';

-#%WGetFiles = (
-# "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/latest-mozilla1.8/sunbird-%version%.en-US.linux-i686.tar.gz" =>
-# "/builds/tinderbox/Sb-Mozilla1.8-l10n/Linux_2.4.21-37.EL_Clobber/sunbird.tar.gz"
-# );
-
%WGetFiles = (
- "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/candidates/0.5rc1/sunbird-%version%.en-US.linux-i686.tar.gz" =>
+ "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/latest-mozilla1.8/sunbird-%version%.en-US.linux-i686.tar.gz" =>
"/builds/tinderbox/Sb-Mozilla1.8-l10n/Linux_2.4.21-37.EL_Clobber/sunbird.tar.gz"
);

@@ -190,8 +185,8 @@
$BuildTree = 'Mozilla1.8-l10n';

#$BuildName = '';
-#$BuildTag = 'MOZILLA_1_8_BRANCH';
-$BuildTag = 'SUNBIRD_0_5_RELEASE';
+$BuildTag = 'MOZILLA_1_8_BRANCH';
+#$BuildTag = 'SUNBIRD_0_5_RELEASE';
#$BuildConfigDir = 'mozilla/config';
#$Topsrcdir = 'mozilla';
</pre>

== Change the Version Number ==

* You check out the branch you just created - use standard "check out code from mozilla cvs method", just substitute in the new branch for your branch parameter
* On this branch, you change the follwing:
* calendar/sunbird/app/module.ver
* calendar/sunbird/config/version.txt
* Then you:
<pre>cvs -d ${CVSROOT} co -r ${PRODUCT_TAG}_BRANCH\
mozilla/calendar/sunbird/app/module.ver mozilla/calendar/sunbird/config/version.txt
</pre>

== Create localized version of Lightning ==

== Tag RC ==
At a specific point in time, when you feel it's right do
<pre>
cvs rtag -r ${PRODUCT_TAG}_BRANCH ${PRODUCT_TAG}_RC mozilla
cvs rtag -r ${PRODUCT_TAG}_BRANCH ${PRODUCT_TAG}_RC l10n
</pre>

of cause you can use something like "..._RCn" where "n" is the number of your release candidate.

== Tag Release ==

Probably the best way to do it is to add the release tag to an already existing RC tag. Make sure to use the latest RC tag...

Could look like this:

<pre>
cvs rtag -r ${PRODUCT_TAG}_RC ${PRODUCT_TAG}_RELEASE mozilla
cvs rtag -r ${PRODUCT_TAG}_RC ${PRODUCT_TAG}_RELEASE l10n
</pre>

== Create Mac universal binaries ==

== Move stuff around on stage server ==

------------------------------------------------------
= '''Release Process Old Page''' =
keeping as reference for now - probaly remove when reworking is done.
------------------------------------------------------

== Create a branch ==
1. Create a branch from the branch you are releasing from this creates a ${PRODUCT_TAG}_BRANCH from the MOZILLA_1_8_BRANCH, you also need to note the time this was done on a page like [[Calendar:Release:Sunbird_0.5]].
<pre>
cvs rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH mozilla
Note time this is done: May 22, 21:37 CDT</pre>
2. Test that the branch was properly created by checking out from the branch.
<pre> cvs co -r ${BRANCH_TAG}_BRANCH mozilla/calendar </pre>

== Change the Version Number ==
* You check out the branch you just created - use standard "check out code from mozilla cvs method", just substitute in the new branch for your branch parameter
* On this branch, you change the follwing:
* calendar/sunbird/app/module.ver
* calendar/sunbird/config/version.txt
* Then you:
<pre>cvs -d ${CVSROOT} co -r ${PRODUCT_TAG}_BRANCH\
mozilla/calendar/sunbird/app/module.ver mozilla/calendar/sunbird/config/version.txt
</pre>

==Create a minibranch==
<pre>
cvs tag -b ${PRODUCT_TAG}_MINIBRANCH calendar/sunbird/app/module.ver \
calendar/sunbird/config/version.txt
cvs up -r ${PRODUCT_TAG}_MINIBRANCH calendar/sunbird/app/module.ver \
calendar/sunbird/config/version.txt
cvs ci -m"bumping version number on calendar/sunbird on minibranch only"
</pre>

* remove firefox stuff from calendar/lightning/install.rdf

== Tag the release ==
* run "date" before you start and use this as date stamp.
* the date should be in UTC and have this format: "yyyy-mm-dd hh:mm +0000"
* You need to use an RC here in case we have RC builds that way RCs will move forward to the release (you can have multiple RC's but there is only one release) so ${RC} becomes 1 for the first attempt to release 0.5
<pre>
screen
cd .. (one up from mozilla)
mkdir -p tags/${PRODUCT_TAG}_RC${RC}
cd tags && ln -s ${PRODUCT_TAG}_RC${RC} ${PRODUCT_TAG}_RELEASE && \
ln -s ${PRODUCT_TAG}_RC${RC} ${PRODUCT_TAG}_RELEASE
</pre>
* Next, check out mozilla/client.mk and any <something>/config/mozconfig files you need with statements like this:
<pre>
cvs co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
mozilla/client.mk
becomes: cvs co -r ${PRODUCT_TAG}_BRANCH -D "2007-05-23 04:00 +0000" mozilla/client.mk
</pre>
* Next, you follow these steps:
<pre>
# pull version files from the version bump minibranch
cvs up -r ${PRODUCT_TAG}_MINIBRANCH ${APP}/app/module.ver \
${APP}/config/version.txt config/milestone.txt

# Create the tag.
cvs tag ${PRODUCT_TAG}_RELEASE 2>&1 | tee ../${PRODUCT_TAG}_RELEASE.log
# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RELEASE.log

# Create the RC tag.
cvs tag ${PRODUCT_TAG}_RC${RC} 2>&1 | tee ../${BRANCH_TAG}_RC${RC}.log
# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RC${RC}.log

# Create a minibranch for the pull scripts so we can change them without
# changing anything on the original branch.
cvs tag -b ${PRODUCT_TAG}_MINIBRANCH client.mk

# Update client.mk to the minibranch you just created.
cvs up -r ${PRODUCT_TAG}_MINIBRANCH client.mk

# Add the new product tag to the client.mk - need to replace the current branch ID
sed "s/${MOZILLA_1_8_BRANCH}/${PRODUCT_TAG}_RELEASE/g" client.mk > client.mk.tmp
mv client.mk.tmp client.mk

# Verify that client.mk only has the changes you expect
cvs diff -u client.mk
# Verify that client.mk has its sticky tag set properly.
cvs status client.mk
cvs commit -m "For $PRODUCT $VERSION, redirect client.mk onto the ${PRODUCT_TAG}_RELEASE tag." client.mk

# Move the release tag onto the modified version of the pull scripts.
# Note that you may have to wait to gain a lock, that is normal.
cvs tag -F ${PRODUCT_TAG}_RELEASE client.mk
cvs tag -F ${PRODUCT_TAG}_RC${RC} client.mk
</pre>

=== Tag Talkback===
* '''NOTE:''' to do this, you need access to talkback, currently only lilmatt has that access on our team.
<pre>
# Create the mofo tag directory.
cd ~cltbld/tags/${PRODUCT_TAG}_RC${RC}
mkdir mofo/
cd mofo/

# Branch Talkback like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT}/mofo rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH mofo

# Check out the talkback files from the branch you want to tag.
cvs -d :ext:cltbld@cvs.mozilla.org:/mofo co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
talkback/fullsoft 2>&1 | tee checkout-output.log

# Create the tag.
cd talkback/fullsoft/
cvs tag ${PRODUCT_TAG}_RELEASE 2>&1 | tee ../${PRODUCT_TAG}_RELEASE.log

# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RELEASE.log
</pre>

=== Tag L10N ===
* Note that you will need L10N access to do this
<pre>
# Create the l10n tag directory.
cd ~cltbld/tags/${PRODUCT_TAG}_RELEASE
mkdir l10n/
cd l10n/

# Branch Locales like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT}/l10n rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH l10n

# Grab list of shipped locales
LOCALES=`awk '{print $1}' < ../cvsroot/mozilla/calendar/locales/shipped-locales`

# Check out the l10n files from the branch you want to tag.
(for l in $LOCALES
do
cvs -d ${CVSROOT}/l10n co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
l10n/${l}
done) 2>&1 | tee checkout-output.log

cd l10n/
</pre>

Use lilmatt's magic L10N script to compile Lightning into Locales. You can find the script in {{bug|352546}}. We will check it into the main tree somewhere (suggested name: m/c/lilmattsmagicbuildtricks). You need to update the .dtd and .properties filenames for the current release.

==Push tag forward on updated l10n files==
In the <code>l10n</code> directory where you originally tagged l10n...
cvs up -r SUNBIRD_0_5_BRANCH
cvs tag -F SUNBIRD_0_5_RELEASE

Calendar Talk:HowToRelease

2007-08-02T13:59:27Z

Ause:

this is a prototype of what i think should be on this page. feel free to correct, extend or partially rewrite.

Calendar:HowToRelease

2007-08-02T13:57:57Z

Ause: /* Overview */

= '''Release Process''' =
== Overview ==
This is a short summery of steps required to do a release of Sunbird/Lightning. For simplicity, these steps are expected to be executed in the order mentioned here. Each step will have a more detailed section below.

To prepare for a release:
* Create a branch in mozilla repository
* Create a branch in l10n repository
* Change Tinderboxes to build form that branch
* Change the Version Number
* Create localized version of Lightning (to be done in the build - see Bug 352546)
* Tag files on the branch to make a RC if required

When the final RC gets approved:
* Tag files on the branch with a release tag
* Create Mac universal binaries (to be done in the build too?)
* Move stuff around on stage server

== Create a branch ==
NOTES:
* If you intend to see these changes, esp. the fixes, in any later release, keep in mind to also commit them to the regular development branch.
* ${PRODUCT_TAG} is the header for the BRANCH - for sunbird 0.7 this will de SUNBIRD_0_7, other releases should follow the same convention
* ${BRANCH_TAG} is made by appending _BRANCH to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_BRANCH
* ${RC_TAG} is made by appending _RC to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_RC
* ${RELEASE_TAG} is made by appending _RELEASE to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_RELEASE

=== mozilla cvs repository ===
1. Create a branch from the branch you are releasing from. This creates a ${PRODUCT_TAG}_BRANCH from the MOZILLA_1_8_BRANCH,
<pre>
cvs rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH mozilla
</pre>
2. Test that the branch was properly created by checking out from the branch.
<pre> cvs co -r ${BRANCH_TAG}_BRANCH mozilla/calendar </pre>

=== l10n cvs repository ===

* Note that you will need L10N access to do this
<pre>
# Branch Locales like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT}/l10n rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH l10n
</pre>

From now on, changes meant to apper in the release are done on this branch.

== Change Tinderboxes for Release ==

"tinderbox-config.pl" files have to be changed to let the tinderboxes pick up the release branch. Also the destination on the stage server needs to be changed.

NOTES:
* be sure to make these changes on the cvs branch the desired tinderbox picks up.

The following sample shows the changes done for linux when switching back from "release mode" to "nightly".

<pre>
Index: tinder-config.pl
===================================================================
RCS file: /cvsroot/mozilla/tools/tinderbox-configs/sunbird/linux/tinder-config.pl,v
retrieving revision 1.26.2.8
retrieving revision 1.26.2.9
diff -u -r1.26.2.8 -r1.26.2.9
--- tinder-config.pl 24 May 2007 16:56:07 -0000 1.26.2.8
+++ tinder-config.pl 28 Jun 2007 20:21:07 -0000 1.26.2.9
@@ -49,8 +49,8 @@
# Tests
$CleanProfile = 1;
$ResetHomeDirForTests = 1;
-$ProductName = "Sunbird";
-#$ProductName = 'Calendar';
+#$ProductName = "Sunbird";
+$ProductName = 'Calendar';
$VendorName = 'Mozilla';

#$RunMozillaTests = 1; # Allow turning off of all tests if needed.
@@ -166,13 +166,8 @@

$LocalizationVersionFile = 'calendar/sunbird/config/version.txt';

-#%WGetFiles = (
-# "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/latest-mozilla1.8/sunbird-%version%.en-US.linux-i686.tar.gz" =>
-# "/builds/tinderbox/Sb-Mozilla1.8-l10n/Linux_2.4.21-37.EL_Clobber/sunbird.tar.gz"
-# );
-
%WGetFiles = (
- "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/candidates/0.5rc1/sunbird-%version%.en-US.linux-i686.tar.gz" =>
+ "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/latest-mozilla1.8/sunbird-%version%.en-US.linux-i686.tar.gz" =>
"/builds/tinderbox/Sb-Mozilla1.8-l10n/Linux_2.4.21-37.EL_Clobber/sunbird.tar.gz"
);

@@ -190,8 +185,8 @@
$BuildTree = 'Mozilla1.8-l10n';

#$BuildName = '';
-#$BuildTag = 'MOZILLA_1_8_BRANCH';
-$BuildTag = 'SUNBIRD_0_5_RELEASE';
+$BuildTag = 'MOZILLA_1_8_BRANCH';
+#$BuildTag = 'SUNBIRD_0_5_RELEASE';
#$BuildConfigDir = 'mozilla/config';
#$Topsrcdir = 'mozilla';
</pre>

== Change the Version Number ==

* You check out the branch you just created - use standard "check out code from mozilla cvs method", just substitute in the new branch for your branch parameter
* On this branch, you change the follwing:
* calendar/sunbird/app/module.ver
* calendar/sunbird/config/version.txt
* Then you:
<pre>cvs -d ${CVSROOT} co -r ${PRODUCT_TAG}_BRANCH\
mozilla/calendar/sunbird/app/module.ver mozilla/calendar/sunbird/config/version.txt
</pre>

== Create localized version of Lightning ==

== Tag RC ==
At a specific point in time, when you feel it's right do
<pre>
cvs rtag -r ${PRODUCT_TAG}_BRANCH ${PRODUCT_TAG}_RC mozilla
cvs rtag -r ${PRODUCT_TAG}_BRANCH ${PRODUCT_TAG}_RC l10n
</pre>

of cause you can use something like "..._RCn" where "n" is the number of your release candidate.

== Tag Release ==

Probably the best way to do it is to add the release tag to an already existing RC tag. Make sure to use the latest RC tag...

Could look like this:

<pre>
cvs rtag -r ${PRODUCT_TAG}_RC ${PRODUCT_TAG}_RELEASE mozilla
cvs rtag -r ${PRODUCT_TAG}_RC ${PRODUCT_TAG}_RELEASE l10n
</pre>

== Create Mac universal binaries ==

== Move stuff around on stage server ==

------------------------------------------------------
= '''Release Process Old Page''' =
keeping as reference for now - probaly remove when reworking is done.
------------------------------------------------------

== Create a branch ==
1. Create a branch from the branch you are releasing from this creates a ${PRODUCT_TAG}_BRANCH from the MOZILLA_1_8_BRANCH, you also need to note the time this was done on a page like [[Calendar:Release:Sunbird_0.5]].
<pre>
cvs rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH mozilla
Note time this is done: May 22, 21:37 CDT</pre>
2. Test that the branch was properly created by checking out from the branch.
<pre> cvs co -r ${BRANCH_TAG}_BRANCH mozilla/calendar </pre>

== Change the Version Number ==
* You check out the branch you just created - use standard "check out code from mozilla cvs method", just substitute in the new branch for your branch parameter
* On this branch, you change the follwing:
* calendar/sunbird/app/module.ver
* calendar/sunbird/config/version.txt
* Then you:
<pre>cvs -d ${CVSROOT} co -r ${PRODUCT_TAG}_BRANCH\
mozilla/calendar/sunbird/app/module.ver mozilla/calendar/sunbird/config/version.txt
</pre>

==Create a minibranch==
<pre>
cvs tag -b ${PRODUCT_TAG}_MINIBRANCH calendar/sunbird/app/module.ver \
calendar/sunbird/config/version.txt
cvs up -r ${PRODUCT_TAG}_MINIBRANCH calendar/sunbird/app/module.ver \
calendar/sunbird/config/version.txt
cvs ci -m"bumping version number on calendar/sunbird on minibranch only"
</pre>

* remove firefox stuff from calendar/lightning/install.rdf

== Tag the release ==
* run "date" before you start and use this as date stamp.
* the date should be in UTC and have this format: "yyyy-mm-dd hh:mm +0000"
* You need to use an RC here in case we have RC builds that way RCs will move forward to the release (you can have multiple RC's but there is only one release) so ${RC} becomes 1 for the first attempt to release 0.5
<pre>
screen
cd .. (one up from mozilla)
mkdir -p tags/${PRODUCT_TAG}_RC${RC}
cd tags && ln -s ${PRODUCT_TAG}_RC${RC} ${PRODUCT_TAG}_RELEASE && \
ln -s ${PRODUCT_TAG}_RC${RC} ${PRODUCT_TAG}_RELEASE
</pre>
* Next, check out mozilla/client.mk and any <something>/config/mozconfig files you need with statements like this:
<pre>
cvs co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
mozilla/client.mk
becomes: cvs co -r ${PRODUCT_TAG}_BRANCH -D "2007-05-23 04:00 +0000" mozilla/client.mk
</pre>
* Next, you follow these steps:
<pre>
# pull version files from the version bump minibranch
cvs up -r ${PRODUCT_TAG}_MINIBRANCH ${APP}/app/module.ver \
${APP}/config/version.txt config/milestone.txt

# Create the tag.
cvs tag ${PRODUCT_TAG}_RELEASE 2>&1 | tee ../${PRODUCT_TAG}_RELEASE.log
# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RELEASE.log

# Create the RC tag.
cvs tag ${PRODUCT_TAG}_RC${RC} 2>&1 | tee ../${BRANCH_TAG}_RC${RC}.log
# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RC${RC}.log

# Create a minibranch for the pull scripts so we can change them without
# changing anything on the original branch.
cvs tag -b ${PRODUCT_TAG}_MINIBRANCH client.mk

# Update client.mk to the minibranch you just created.
cvs up -r ${PRODUCT_TAG}_MINIBRANCH client.mk

# Add the new product tag to the client.mk - need to replace the current branch ID
sed "s/${MOZILLA_1_8_BRANCH}/${PRODUCT_TAG}_RELEASE/g" client.mk > client.mk.tmp
mv client.mk.tmp client.mk

# Verify that client.mk only has the changes you expect
cvs diff -u client.mk
# Verify that client.mk has its sticky tag set properly.
cvs status client.mk
cvs commit -m "For $PRODUCT $VERSION, redirect client.mk onto the ${PRODUCT_TAG}_RELEASE tag." client.mk

# Move the release tag onto the modified version of the pull scripts.
# Note that you may have to wait to gain a lock, that is normal.
cvs tag -F ${PRODUCT_TAG}_RELEASE client.mk
cvs tag -F ${PRODUCT_TAG}_RC${RC} client.mk
</pre>

=== Tag Talkback===
* '''NOTE:''' to do this, you need access to talkback, currently only lilmatt has that access on our team.
<pre>
# Create the mofo tag directory.
cd ~cltbld/tags/${PRODUCT_TAG}_RC${RC}
mkdir mofo/
cd mofo/

# Branch Talkback like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT}/mofo rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH mofo

# Check out the talkback files from the branch you want to tag.
cvs -d :ext:cltbld@cvs.mozilla.org:/mofo co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
talkback/fullsoft 2>&1 | tee checkout-output.log

# Create the tag.
cd talkback/fullsoft/
cvs tag ${PRODUCT_TAG}_RELEASE 2>&1 | tee ../${PRODUCT_TAG}_RELEASE.log

# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RELEASE.log
</pre>

=== Tag L10N ===
* Note that you will need L10N access to do this
<pre>
# Create the l10n tag directory.
cd ~cltbld/tags/${PRODUCT_TAG}_RELEASE
mkdir l10n/
cd l10n/

# Branch Locales like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT}/l10n rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH l10n

# Grab list of shipped locales
LOCALES=`awk '{print $1}' < ../cvsroot/mozilla/calendar/locales/shipped-locales`

# Check out the l10n files from the branch you want to tag.
(for l in $LOCALES
do
cvs -d ${CVSROOT}/l10n co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
l10n/${l}
done) 2>&1 | tee checkout-output.log

cd l10n/
</pre>

Use lilmatt's magic L10N script to compile Lightning into Locales. You can find the script in {{bug|352546}}. We will check it into the main tree somewhere (suggested name: m/c/lilmattsmagicbuildtricks). You need to update the .dtd and .properties filenames for the current release.

==Push tag forward on updated l10n files==
In the <code>l10n</code> directory where you originally tagged l10n...
cvs up -r SUNBIRD_0_5_BRANCH
cvs tag -F SUNBIRD_0_5_RELEASE

Calendar:HowToRelease

2007-08-02T13:56:08Z

Ause: /* Release Process */

= '''Release Process''' =
== Overview ==
This is a short summery of steps required to do a release of Sunbird/Lightning. For simplicity, these steps are expected to be executed in the order mentioned here. Each step will have a more detaild section below.

To prepare for a release:
* Create a branch in mozilla repository
* Create a branch in l10n repository
* Change Tinderboxes to build form that branch
* Change the Version Number
* Create localized version of Lightning (to be done in the build - see Bug 352546)
* Tag files on the branch to makr a RC if required

When the final RC gets approved:
* Tag files on the branch with a release tag
* Create Mac universal binaries (to be done in the build too?)
* Move stuff around on stage server

== Create a branch ==
NOTES:
* If you intend to see these changes, esp. the fixes, in any later release, keep in mind to also commit them to the regular development branch.
* ${PRODUCT_TAG} is the header for the BRANCH - for sunbird 0.7 this will de SUNBIRD_0_7, other releases should follow the same convention
* ${BRANCH_TAG} is made by appending _BRANCH to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_BRANCH
* ${RC_TAG} is made by appending _RC to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_RC
* ${RELEASE_TAG} is made by appending _RELEASE to the ${PRODUCT_TAG} for example, SUNBIRD_0_7_RELEASE

=== mozilla cvs repository ===
1. Create a branch from the branch you are releasing from. This creates a ${PRODUCT_TAG}_BRANCH from the MOZILLA_1_8_BRANCH,
<pre>
cvs rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH mozilla
</pre>
2. Test that the branch was properly created by checking out from the branch.
<pre> cvs co -r ${BRANCH_TAG}_BRANCH mozilla/calendar </pre>

=== l10n cvs repository ===

* Note that you will need L10N access to do this
<pre>
# Branch Locales like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT}/l10n rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH l10n
</pre>

From now on, changes meant to apper in the release are done on this branch.

== Change Tinderboxes for Release ==

"tinderbox-config.pl" files have to be changed to let the tinderboxes pick up the release branch. Also the destination on the stage server needs to be changed.

NOTES:
* be sure to make these changes on the cvs branch the desired tinderbox picks up.

The following sample shows the changes done for linux when switching back from "release mode" to "nightly".

<pre>
Index: tinder-config.pl
===================================================================
RCS file: /cvsroot/mozilla/tools/tinderbox-configs/sunbird/linux/tinder-config.pl,v
retrieving revision 1.26.2.8
retrieving revision 1.26.2.9
diff -u -r1.26.2.8 -r1.26.2.9
--- tinder-config.pl 24 May 2007 16:56:07 -0000 1.26.2.8
+++ tinder-config.pl 28 Jun 2007 20:21:07 -0000 1.26.2.9
@@ -49,8 +49,8 @@
# Tests
$CleanProfile = 1;
$ResetHomeDirForTests = 1;
-$ProductName = "Sunbird";
-#$ProductName = 'Calendar';
+#$ProductName = "Sunbird";
+$ProductName = 'Calendar';
$VendorName = 'Mozilla';

#$RunMozillaTests = 1; # Allow turning off of all tests if needed.
@@ -166,13 +166,8 @@

$LocalizationVersionFile = 'calendar/sunbird/config/version.txt';

-#%WGetFiles = (
-# "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/latest-mozilla1.8/sunbird-%version%.en-US.linux-i686.tar.gz" =>
-# "/builds/tinderbox/Sb-Mozilla1.8-l10n/Linux_2.4.21-37.EL_Clobber/sunbird.tar.gz"
-# );
-
%WGetFiles = (
- "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/candidates/0.5rc1/sunbird-%version%.en-US.linux-i686.tar.gz" =>
+ "http://stage.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/latest-mozilla1.8/sunbird-%version%.en-US.linux-i686.tar.gz" =>
"/builds/tinderbox/Sb-Mozilla1.8-l10n/Linux_2.4.21-37.EL_Clobber/sunbird.tar.gz"
);

@@ -190,8 +185,8 @@
$BuildTree = 'Mozilla1.8-l10n';

#$BuildName = '';
-#$BuildTag = 'MOZILLA_1_8_BRANCH';
-$BuildTag = 'SUNBIRD_0_5_RELEASE';
+$BuildTag = 'MOZILLA_1_8_BRANCH';
+#$BuildTag = 'SUNBIRD_0_5_RELEASE';
#$BuildConfigDir = 'mozilla/config';
#$Topsrcdir = 'mozilla';
</pre>

== Change the Version Number ==

* You check out the branch you just created - use standard "check out code from mozilla cvs method", just substitute in the new branch for your branch parameter
* On this branch, you change the follwing:
* calendar/sunbird/app/module.ver
* calendar/sunbird/config/version.txt
* Then you:
<pre>cvs -d ${CVSROOT} co -r ${PRODUCT_TAG}_BRANCH\
mozilla/calendar/sunbird/app/module.ver mozilla/calendar/sunbird/config/version.txt
</pre>

== Create localized version of Lightning ==

== Tag RC ==
At a specific point in time, when you feel it's right do
<pre>
cvs rtag -r ${PRODUCT_TAG}_BRANCH ${PRODUCT_TAG}_RC mozilla
cvs rtag -r ${PRODUCT_TAG}_BRANCH ${PRODUCT_TAG}_RC l10n
</pre>

of cause you can use something like "..._RCn" where "n" is the number of your release candidate.

== Tag Release ==

Probably the best way to do it is to add the release tag to an already existing RC tag. Make sure to use the latest RC tag...

Could look like this:

<pre>
cvs rtag -r ${PRODUCT_TAG}_RC ${PRODUCT_TAG}_RELEASE mozilla
cvs rtag -r ${PRODUCT_TAG}_RC ${PRODUCT_TAG}_RELEASE l10n
</pre>

== Create Mac universal binaries ==

== Move stuff around on stage server ==

------------------------------------------------------
= '''Release Process Old Page''' =
keeping as reference for now - probaly remove when reworking is done.
------------------------------------------------------

== Create a branch ==
1. Create a branch from the branch you are releasing from this creates a ${PRODUCT_TAG}_BRANCH from the MOZILLA_1_8_BRANCH, you also need to note the time this was done on a page like [[Calendar:Release:Sunbird_0.5]].
<pre>
cvs rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH mozilla
Note time this is done: May 22, 21:37 CDT</pre>
2. Test that the branch was properly created by checking out from the branch.
<pre> cvs co -r ${BRANCH_TAG}_BRANCH mozilla/calendar </pre>

== Change the Version Number ==
* You check out the branch you just created - use standard "check out code from mozilla cvs method", just substitute in the new branch for your branch parameter
* On this branch, you change the follwing:
* calendar/sunbird/app/module.ver
* calendar/sunbird/config/version.txt
* Then you:
<pre>cvs -d ${CVSROOT} co -r ${PRODUCT_TAG}_BRANCH\
mozilla/calendar/sunbird/app/module.ver mozilla/calendar/sunbird/config/version.txt
</pre>

==Create a minibranch==
<pre>
cvs tag -b ${PRODUCT_TAG}_MINIBRANCH calendar/sunbird/app/module.ver \
calendar/sunbird/config/version.txt
cvs up -r ${PRODUCT_TAG}_MINIBRANCH calendar/sunbird/app/module.ver \
calendar/sunbird/config/version.txt
cvs ci -m"bumping version number on calendar/sunbird on minibranch only"
</pre>

* remove firefox stuff from calendar/lightning/install.rdf

== Tag the release ==
* run "date" before you start and use this as date stamp.
* the date should be in UTC and have this format: "yyyy-mm-dd hh:mm +0000"
* You need to use an RC here in case we have RC builds that way RCs will move forward to the release (you can have multiple RC's but there is only one release) so ${RC} becomes 1 for the first attempt to release 0.5
<pre>
screen
cd .. (one up from mozilla)
mkdir -p tags/${PRODUCT_TAG}_RC${RC}
cd tags && ln -s ${PRODUCT_TAG}_RC${RC} ${PRODUCT_TAG}_RELEASE && \
ln -s ${PRODUCT_TAG}_RC${RC} ${PRODUCT_TAG}_RELEASE
</pre>
* Next, check out mozilla/client.mk and any <something>/config/mozconfig files you need with statements like this:
<pre>
cvs co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
mozilla/client.mk
becomes: cvs co -r ${PRODUCT_TAG}_BRANCH -D "2007-05-23 04:00 +0000" mozilla/client.mk
</pre>
* Next, you follow these steps:
<pre>
# pull version files from the version bump minibranch
cvs up -r ${PRODUCT_TAG}_MINIBRANCH ${APP}/app/module.ver \
${APP}/config/version.txt config/milestone.txt

# Create the tag.
cvs tag ${PRODUCT_TAG}_RELEASE 2>&1 | tee ../${PRODUCT_TAG}_RELEASE.log
# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RELEASE.log

# Create the RC tag.
cvs tag ${PRODUCT_TAG}_RC${RC} 2>&1 | tee ../${BRANCH_TAG}_RC${RC}.log
# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RC${RC}.log

# Create a minibranch for the pull scripts so we can change them without
# changing anything on the original branch.
cvs tag -b ${PRODUCT_TAG}_MINIBRANCH client.mk

# Update client.mk to the minibranch you just created.
cvs up -r ${PRODUCT_TAG}_MINIBRANCH client.mk

# Add the new product tag to the client.mk - need to replace the current branch ID
sed "s/${MOZILLA_1_8_BRANCH}/${PRODUCT_TAG}_RELEASE/g" client.mk > client.mk.tmp
mv client.mk.tmp client.mk

# Verify that client.mk only has the changes you expect
cvs diff -u client.mk
# Verify that client.mk has its sticky tag set properly.
cvs status client.mk
cvs commit -m "For $PRODUCT $VERSION, redirect client.mk onto the ${PRODUCT_TAG}_RELEASE tag." client.mk

# Move the release tag onto the modified version of the pull scripts.
# Note that you may have to wait to gain a lock, that is normal.
cvs tag -F ${PRODUCT_TAG}_RELEASE client.mk
cvs tag -F ${PRODUCT_TAG}_RC${RC} client.mk
</pre>

=== Tag Talkback===
* '''NOTE:''' to do this, you need access to talkback, currently only lilmatt has that access on our team.
<pre>
# Create the mofo tag directory.
cd ~cltbld/tags/${PRODUCT_TAG}_RC${RC}
mkdir mofo/
cd mofo/

# Branch Talkback like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT}/mofo rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH mofo

# Check out the talkback files from the branch you want to tag.
cvs -d :ext:cltbld@cvs.mozilla.org:/mofo co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
talkback/fullsoft 2>&1 | tee checkout-output.log

# Create the tag.
cd talkback/fullsoft/
cvs tag ${PRODUCT_TAG}_RELEASE 2>&1 | tee ../${PRODUCT_TAG}_RELEASE.log

# Look for errors
grep -v "^T" ../${PRODUCT_TAG}_RELEASE.log
</pre>

=== Tag L10N ===
* Note that you will need L10N access to do this
<pre>
# Create the l10n tag directory.
cd ~cltbld/tags/${PRODUCT_TAG}_RELEASE
mkdir l10n/
cd l10n/

# Branch Locales like we did for the SUNBIRD_0_5_RELEASE earlier:
cvs -d ${CVSROOT}/l10n rtag -r MOZILLA_1_8_BRANCH -b ${PRODUCT_TAG}_BRANCH l10n

# Grab list of shipped locales
LOCALES=`awk '{print $1}' < ../cvsroot/mozilla/calendar/locales/shipped-locales`

# Check out the l10n files from the branch you want to tag.
(for l in $LOCALES
do
cvs -d ${CVSROOT}/l10n co \
-r $BRANCH_TAG \
-D "$PULL_DATE" \
l10n/${l}
done) 2>&1 | tee checkout-output.log

cd l10n/
</pre>

Use lilmatt's magic L10N script to compile Lightning into Locales. You can find the script in {{bug|352546}}. We will check it into the main tree somewhere (suggested name: m/c/lilmattsmagicbuildtricks). You need to update the .dtd and .properties filenames for the current release.

==Push tag forward on updated l10n files==
In the <code>l10n</code> directory where you originally tagged l10n...
cvs up -r SUNBIRD_0_5_BRANCH
cvs tag -F SUNBIRD_0_5_RELEASE