Difference between revisions of "Lazarus release engineering"

From Lazarus wiki
Jump to navigationJump to search
m (Categorised page)
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= The Lazarus Release engineering process =
 
  
== Notes ==
+
{{Note|This page is still work in progress. For feedback please use our mailing list.}}
 
 
This page is still work in progress. For feedback please use our mailing list.
 
  
 
== Checklist ==
 
== Checklist ==
Line 9: Line 6:
 
<table width="100%"><tr valign="top">
 
<table width="100%"><tr valign="top">
 
<td style="min-width:40%">
 
<td style="min-width:40%">
 +
 
=== Major Release ===
 
=== Major Release ===
  
==== Decide on new Release ====
+
* Decide on new release
* Decide
 
 
** Check internally with the team  
 
** Check internally with the team  
 
** Decide on approx Date for first RC (date may change). This may be optional.
 
** Decide on approx Date for first RC (date may change). This may be optional.
Line 22: Line 19:
 
** <u>Public announcement</u> with approx RC date (if available).
 
** <u>Public announcement</u> with approx RC date (if available).
  
==== For each Release Candidate ====
+
=== For each Release Candidate ===
 
* Between 1 and 2 weeks before RC is due
 
* Between 1 and 2 weeks before RC is due
 
** Check internally with the team  
 
** Check internally with the team  
Line 34: Line 31:
 
Typical life time of an RC can be expected to be between 3 and 6 weeks. But in the end will be decided at the discretion of the team.
 
Typical life time of an RC can be expected to be between 3 and 6 weeks. But in the end will be decided at the discretion of the team.
  
==== For the Release ====
+
=== For the Release ===
 
* At least 2 weeks before Release
 
* At least 2 weeks before Release
 
** Check internally with the team  
 
** Check internally with the team  
Line 55: Line 52:
 
=== Minor Release ===
 
=== Minor Release ===
  
==== Decide on new Release (Day: approx -4 / Durance 3-4 days) ====
+
* Decide on new Release (Day: approx -4 / Duration 3-4 days)
* Decide
 
 
** Check internally with the team (3 to 4 days)
 
** Check internally with the team (3 to 4 days)
 
** Release Date will be 2 weeks from announcement (1 week for community feedback)
 
** Release Date will be 2 weeks from announcement (1 week for community feedback)
Line 62: Line 58:
 
** Update fixes page on wiki (New section "Fixes for ..." next release
 
** Update fixes page on wiki (New section "Fixes for ..." next release
  
==== Announce upcoming Release (Day: 0 / Durance 7-8 days) ====
+
* Announce upcoming Release (Day: 0 / Duration 7-8 days)
 
+
** <u>Special announcement</u> for translators.
* <u>Special announcement</u> for translators.
+
** <u>Public announcement</u> with approx date.
* <u>Public announcement</u> with approx date.
+
*** Mail
** Mail
+
*** Forum
** Forum
 
 
: Ask for  
 
: Ask for  
 
:*new regressions
 
:*new regressions
Line 77: Line 72:
 
Depending on feedback received: reschedule and if needed re-announce.
 
Depending on feedback received: reschedule and if needed re-announce.
  
==== Approve Release (Start at day: 7 to 9 / Durance 3/4 days) ====
+
==== Approve Release (Start at day: 7 to 9 / Duration 3/4 days) ====
  
 
* Check internally with the team (3 to 4 days)
 
* Check internally with the team (3 to 4 days)
Line 83: Line 78:
 
Depending on feedback received: reschedule and if needed re-announce.
 
Depending on feedback received: reschedule and if needed re-announce.
  
==== Prepare Release (Start at day: 10 to 12 / Durance 3/4 days) ====
+
==== Prepare Release (Start at day: 10 to 12 / Duration 3/4 days) ====
  
 
* TAG SVN
 
* TAG SVN
* Build docs => update binaries wiki
+
* Build docs => update binaries svn
 
* Start building
 
* Start building
 
* Build Release binaries
 
* Build Release binaries
Line 97: Line 92:
 
** Optional: Update webpage to contain checksums
 
** Optional: Update webpage to contain checksums
 
* Update web-page svn with new download links (to be published *after* release)
 
* Update web-page svn with new download links (to be published *after* release)
 
  
 
==== Release (At day 14 to 16) ====
 
==== Release (At day 14 to 16) ====
Line 110: Line 104:
 
** Sourceforge news
 
** Sourceforge news
  
* Update web-page
+
* Update web-page (Download-links / Checksums)
  
  
Line 116: Line 110:
 
</tr></table>
 
</tr></table>
  
=== Merging fixes ===
+
== Merging fixes ==
  
 
Team members will add any revision that should be merged to the "fixes branch" page (see "Related Pages").
 
Team members will add any revision that should be merged to the "fixes branch" page (see "Related Pages").
Line 126: Line 120:
 
to request revisions to be added.
 
to request revisions to be added.
 
   
 
   
 +
== Other Items ==
  
=== Other Items ===
 
 
In addition to the items on the checklist:
 
In addition to the items on the checklist:
 
* create new targets on Mantis, with each RC, and for the Release
 
* create new targets on Mantis, with each RC, and for the Release
Line 145: Line 139:
 
The editing of the Checklist above should be reserved to the team. Thanks.
 
The editing of the Checklist above should be reserved to the team. Thanks.
  
= How to merge =
+
== How to merge ==
 
 
 
 
  
 
The lazarus developers have decided to use the native svn merge for this branch. Other branches used the svnmerge.py script to manage the revisions to be merged.
 
The lazarus developers have decided to use the native svn merge for this branch. Other branches used the svnmerge.py script to manage the revisions to be merged.
Line 154: Line 146:
  
 
[[SVN_Migration#Merge_with_plain_svn]]
 
[[SVN_Migration#Merge_with_plain_svn]]
 +
 
=== Using TortoiseSVN ===
 
=== Using TortoiseSVN ===
 
As noted in the link above using TortoiseSVN is more or less self explaining.  
 
As noted in the link above using TortoiseSVN is more or less self explaining.  
Line 164: Line 157:
  
 
=== Show list of revision that can be merged ===
 
=== Show list of revision that can be merged ===
 +
 
In the lazarus fixes_1_0 directory do:
 
In the lazarus fixes_1_0 directory do:
 
  svn mergeinfo ^/trunk --show-revs eligible
 
  svn mergeinfo ^/trunk --show-revs eligible
Line 170: Line 164:
  
 
=== Show list of revision that have been merged ===
 
=== Show list of revision that have been merged ===
 +
 
In the lazarus fixes_1_0 directory do:
 
In the lazarus fixes_1_0 directory do:
 
  svn mergeinfo ^/trunk --show-revs merged
 
  svn mergeinfo ^/trunk --show-revs merged
  
 
=== Merging revisions from trunk ===
 
=== Merging revisions from trunk ===
 +
 
To merge one or more revisions from trunk, use the svn merge command. For example to merge revision 36506 and 36510 use:
 
To merge one or more revisions from trunk, use the svn merge command. For example to merge revision 36506 and 36510 use:
 
   svn merge -c 36506,36510 ^/trunk
 
   svn merge -c 36506,36510 ^/trunk
Line 187: Line 183:
  
 
=== Blocking a revision to be merged ===
 
=== Blocking a revision to be merged ===
 +
 
Sometimes you want to block a revision to be merged, i.e. you want to make sure that this revision is never merged to the fixes branch, for example, because it contains a new feature or it contains a version number change not applicable to the fixes branch, but only to trunk. To block revision 36507, use:
 
Sometimes you want to block a revision to be merged, i.e. you want to make sure that this revision is never merged to the fixes branch, for example, because it contains a new feature or it contains a version number change not applicable to the fixes branch, but only to trunk. To block revision 36507, use:
 
  svn merge -c 36507 --record-only ^/trunk
 
  svn merge -c 36507 --record-only ^/trunk
Line 196: Line 193:
 
  svn commit -F svnmerge-commit-message.txt
 
  svn commit -F svnmerge-commit-message.txt
  
 +
== Previous releases ==
 +
 +
* [[Lazarus 0.9.30 todo]]
 +
* [[Lazarus 0.9.28 todo]]
 +
* [[Detailed Lazarus 0.9.22 todo|Lazarus 0.9.22 todo]]
 +
 +
* [[Lazarus 0.9.30.2 release plan]]
 +
* [[Lazarus 0.9.28.2 release plan]]
 +
 +
== See also ==
 +
 +
* [[Detailed Lazarus release template todo]]
 +
 +
== Related pages ==
  
= Related pages =
 
 
{{Navbar Lazarus Release Notes}}
 
{{Navbar Lazarus Release Notes}}
 +
 +
[[Category:Lazarus]]
 +
[[Category:Development]]
 +
[[Category:Release engineering]]

Revision as of 04:07, 26 August 2020

Light bulb  Note: This page is still work in progress. For feedback please use our mailing list.

Checklist

Major Release

  • Decide on new release
    • Check internally with the team
    • Decide on approx Date for first RC (date may change). This may be optional.
  • Prepare
    • Create fixes branch in SVN
    • Create fixes page on wiki
  • Announce
    • Special announcement for translators.
    • Public announcement with approx RC date (if available).

For each Release Candidate

  • Between 1 and 2 weeks before RC is due
    • Check internally with the team
    • Public reminder/announcement that RC is due.
    • If needed: Reschedule/Delay
  • Publish the Release Candidate
    • Tag RC in SVN
    • Build and upload
    • Public announcement of RC

Typical life time of an RC can be expected to be between 3 and 6 weeks. But in the end will be decided at the discretion of the team.

For the Release

  • At least 2 weeks before Release
    • Check internally with the team
    • Public reminder/announcement that Release is due. No more RC planned.
    • Repeat Special announcement for translators.
  • 1 week before Release - Depending on feedback (the team should have 3 or 4 days time to discuss this):
      • keep decision to release
      • move date of release
      • schedule another RC
    • 3 to 5 days later: Public announcement of above decision, if a change to the plan was made.
  • Make the Release
    • Tag RC in SVN
    • Build and upload
    • Public announcement of Release


Minor Release

  • Decide on new Release (Day: approx -4 / Duration 3-4 days)
    • Check internally with the team (3 to 4 days)
    • Release Date will be 2 weeks from announcement (1 week for community feedback)
  • Prepare
    • Update fixes page on wiki (New section "Fixes for ..." next release
  • Announce upcoming Release (Day: 0 / Duration 7-8 days)
    • Special announcement for translators.
    • Public announcement with approx date.
      • Mail
      • Forum
Ask for
  • new regressions
  • missing merges

Community has about 1 week to respond. Urgent matters can still be reported during "approve" phase.

Depending on feedback received: reschedule and if needed re-announce.

Approve Release (Start at day: 7 to 9 / Duration 3/4 days)

  • Check internally with the team (3 to 4 days)

Depending on feedback received: reschedule and if needed re-announce.

Prepare Release (Start at day: 10 to 12 / Duration 3/4 days)

  • TAG SVN
  • Build docs => update binaries svn
  • Start building
  • Build Release binaries
    • Test
  • Upload (staged)

At the same time:

  • Update mantis
  • Collect checksums and commit to web-page svn
    • Optional: Update webpage to contain checksums
  • Update web-page svn with new download links (to be published *after* release)

Release (At day 14 to 16)

  • Make files public on Sourceforge (un-stage)
    • Set files as current release
  • Public announcement of Release
    • Mail
    • Forum
    • Twitter
    • Sourceforge news
  • Update web-page (Download-links / Checksums)


Merging fixes

Team members will add any revision that should be merged to the "fixes branch" page (see "Related Pages").

User can contact Team members

  • on the forum
  • on the mail list
  • on open & assigned mantis reports

to request revisions to be added.

Other Items

In addition to the items on the checklist:

  • create new targets on Mantis, with each RC, and for the Release
  • Publish checksums on webpage
  • Update links on webpage
  • Updating of help files
  • Announcements for Translators

TODO: Decide on channels for public feedback on:

  • Open regressions
  • Missing merges

Checklist (Suggestions)

Please add suggestions here. The editing of the Checklist above should be reserved to the team. Thanks.

How to merge

The lazarus developers have decided to use the native svn merge for this branch. Other branches used the svnmerge.py script to manage the revisions to be merged.

  • TODO: Maybe this information should be put in a separate page.

SVN_Migration#Merge_with_plain_svn

Using TortoiseSVN

As noted in the link above using TortoiseSVN is more or less self explaining.

  • TODO: add some screen shots.

When committing, in the recent messages a nice commit message is available.

Tested with TortoiseSVN 1.7.6, SVN 1.7.4.

Show list of revision that can be merged

In the lazarus fixes_1_0 directory do:

svn mergeinfo ^/trunk --show-revs eligible

Or if you don't have a fixes directory checked out, you can pass the URL path of the fixes branch:

svn mergeinfo ^/trunk http://svn.freepascal.org/svn/lazarus/branches/fixes_1_0 --show-revs eligible

Show list of revision that have been merged

In the lazarus fixes_1_0 directory do:

svn mergeinfo ^/trunk --show-revs merged

Merging revisions from trunk

To merge one or more revisions from trunk, use the svn merge command. For example to merge revision 36506 and 36510 use:

 svn merge -c 36506,36510 ^/trunk

To generate a commit log message, use:

svn log ^/trunk -c 36506,36510 > svnmerge-commit-message.txt

Edit svnmerge-commit-message.txt with your favorite text editor and add a first line like:

Merged revision 36506,36510 from /trunk.

Commit this with:

svn commit -F svnmerge-commit-message.txt

Blocking a revision to be merged

Sometimes you want to block a revision to be merged, i.e. you want to make sure that this revision is never merged to the fixes branch, for example, because it contains a new feature or it contains a version number change not applicable to the fixes branch, but only to trunk. To block revision 36507, use:

svn merge -c 36507 --record-only ^/trunk

Then you can create a log message with:

svn log ^/trunk -c 36507 > svnmerge-commit-message.txt

Edit svnmerge-commit-message.txt with your favorite text editor and add first line like:

Blocked revision 36507 from /trunk

Then commit this change:

svn commit -F svnmerge-commit-message.txt

Previous releases

See also

Related pages