Sign in Join
Wiki copytemporary

Lazarus release engineering: what changed

Revision 0 to 1. Removed lines have a minus sign; added lines have a plus sign.

Title: Lazarus release engineering

OldNewLine
1+> **Note:** This page is still work in progress. For feedback please use our mailing list.
2+
3+## Checklist
4+
5+<table width="100%">
6+
7+<tr valign="top">
8+
9+<td style="min-width:40%">
10+
11+### Major Release
12+
13+- Decide on new release
14+ - Check internally with the team
15+ - Decide on approx Date for first RC (date may change). This may be optional.
16+- Prepare
17+ - Create fixes branch in SVN
18+ - Create fixes page on wiki
19+- Announce
20+ - <u>Special announcement</u> for translators.
21+ - <u>Public announcement</u> with approx RC date (if available).
22+
23+### For each Release Candidate
24+
25+- Between 1 and 2 weeks before RC is due
26+ - Check internally with the team
27+ - <u>Public reminder/announcement</u> that RC is due.
28+ - If needed: Reschedule/Delay
29+- Publish the Release Candidate
30+ - Tag RC in SVN
31+ - Build and upload
32+ - <u>Public announcement</u> of RC
33+
34+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.
35+
36+### For the Release
37+
38+- At least 2 weeks before Release
39+ - Check internally with the team
40+ - Public reminder/announcement that Release is due. No more RC planned.
41+ - Repeat <u>Special announcement</u> for translators.
42+- 1 week before Release - Depending on feedback (the team should have 3 or 4 days time to discuss this):
43+ - - keep decision to release
44+ - move date of release
45+ - schedule another RC
46+ - 3 to 5 days later: <u>Public announcement</u> of above decision, if a change to the plan was made.
47+- Make the Release
48+ - Tag RC in SVN
49+ - Build and upload
50+ - <u>Public announcement</u> of Release
51+
52+</td>
53+
54+<td style="min-width:40%">
55+
56+### Minor Release
57+
58+- Decide on new Release (Day: approx -4 / Duration 3-4 days)
59+ - Check internally with the team (3 to 4 days)
60+ - Release Date will be 2 weeks from announcement (1 week for community feedback)
61+- Prepare
62+ - Update fixes page on wiki (New section "Fixes for ..." next release
63+
64+- Announce upcoming Release (Day: 0 / Duration 7-8 days)
65+ - <u>Special announcement</u> for translators.
66+ - <u>Public announcement</u> with approx date.
67+ - Mail
68+ - Forum
69+
70+
71+Ask for
72+
73+- new regressions
74+- missing merges
75+
76+Community has about 1 week to respond. Urgent matters can still be reported during "approve" phase.
77+
78+Depending on feedback received: reschedule and if needed re-announce.
79+
80+#### Approve Release (Start at day: 7 to 9 / Duration 3/4 days)
81+
82+- Check internally with the team (3 to 4 days)
83+
84+Depending on feedback received: reschedule and if needed re-announce.
85+
86+#### Prepare Release (Start at day: 10 to 12 / Duration 3/4 days)
87+
88+- TAG SVN
89+- Build docs =\> update binaries svn
90+- Start building
91+- Build Release binaries
92+ - Test
93+- Upload (staged)
94+
95+At the same time:
96+
97+- Update mantis
98+- Collect checksums and commit to web-page svn
99+ - Optional: Update webpage to contain checksums
100+- Update web-page svn with new download links (to be published *after* release)
101+
102+#### Release (At day 14 to 16)
103+
104+- Make files public on Sourceforge (un-stage)
105+ - Set files as current release
106+
107+- <u>Public announcement</u> of Release
108+ - Mail
109+ - Forum
110+ - Twitter
111+ - Sourceforge news
112+
113+- Update web-page (Download-links / Checksums)
114+
115+</td>
116+
117+</tr>
118+
119+</table>
120+
121+## Merging fixes
122+
123+Team members will add any revision that should be merged to the "fixes branch" page (see "Related Pages").
124+
125+User can contact Team members
126+
127+- on the forum
128+- on the mail list
129+- on open & assigned mantis reports
130+
131+to request revisions to be added.
132+
133+## Other Items
134+
135+In addition to the items on the checklist:
136+
137+- create new targets on Mantis, with each RC, and for the Release
138+- Publish checksums on webpage
139+- Update links on webpage
140+- Updating of help files
141+- Announcements for Translators
142+
143+TODO: Decide on channels for public feedback on:
144+
145+- Open regressions
146+- Missing merges
147+
148+## Checklist (Suggestions)
149+
150+Please add suggestions here. The editing of the Checklist above should be reserved to the team. Thanks.
151+
152+## How to merge
153+
154+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.
155+
156+- TODO: Maybe this information should be put in a separate page.
157+
158+[[SVN Migration|SVN_Migration#Merge_with_plain_svn]]
159+
160+### Using TortoiseSVN
161+
162+As noted in the link above using TortoiseSVN is more or less self explaining.
163+
164+- TODO: add some screen shots.
165+
166+When committing, in the recent messages a nice commit message is available.
167+
168+Tested with TortoiseSVN 1.7.6, SVN 1.7.4.
169+
170+### Show list of revision that can be merged
171+
172+In the lazarus fixes_1_0 directory do:
173+
174+`svn mergeinfo ^/trunk --show-revs eligible`
175+
176+Or if you don't have a fixes directory checked out, you can pass the URL path of the fixes branch:
177+
178+`svn mergeinfo ^/trunk `[`http://svn.freepascal.org/svn/lazarus/branches/fixes_1_0`](http://svn.freepascal.org/svn/lazarus/branches/fixes_1_0)` --show-revs eligible`
179+
180+### Show list of revision that have been merged
181+
182+In the lazarus fixes_1_0 directory do:
183+
184+`svn mergeinfo ^/trunk --show-revs merged`
185+
186+### Merging revisions from trunk
187+
188+To merge one or more revisions from trunk, use the svn merge command. For example to merge revision 36506 and 36510 use:
189+
190+` svn merge -c 36506,36510 ^/trunk`
191+
192+To generate a commit log message, use:
193+
194+`svn log ^/trunk -c 36506,36510 > svnmerge-commit-message.txt`
195+
196+Edit svnmerge-commit-message.txt with your favorite text editor and add a first line like:
197+
198+`Merged revision 36506,36510 from /trunk.`
199+
200+Commit this with:
201+
202+`svn commit -F svnmerge-commit-message.txt`
203+
204+### Blocking a revision to be merged
205+
206+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:
207+
208+`svn merge -c 36507 --record-only ^/trunk`
209+
210+Then you can create a log message with:
211+
212+`svn log ^/trunk -c 36507 > svnmerge-commit-message.txt`
213+
214+Edit svnmerge-commit-message.txt with your favorite text editor and add first line like:
215+
216+`Blocked revision 36507 from /trunk`
217+
218+Then commit this change:
219+
220+`svn commit -F svnmerge-commit-message.txt`
221+
222+## Previous releases
223+
224+- [[Lazarus 0.9.30 todo]]
225+- [[Lazarus 0.9.28 todo]]
226+- [[Detailed Lazarus 0.9.22 todo|Lazarus 0.9.22 todo]]
227+
228+- [[Lazarus 0.9.30.2 release plan]]
229+- [[Lazarus 0.9.28.2 release plan]]
230+
231+## See also
232+
233+- [[Detailed Lazarus release template todo]]
234+
235+## Related pages
236+
237+---
238+*From the Free Pascal wiki, page "Lazarus release engineering", as it stood on 2022-08-16 after a change by Skalogryz, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's [[Licensing]] page. If you have concerns about this material, [message the admin](/wiki-contact).*
239+Category: Development
240+Category: Lazarus
241+Category: Release engineering
242+Category: SOPs

Back to history