Lazarus release engineering
The Lazarus Release engineering process
Checklist
Decide on new Release
- Check internally with the team
- Decide on approx Date for first RC (date may change). This may be optional.
- In case of new major Release
- Create fixes branch
- Create fixes page on wiki
- 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
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