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