source: rtems-docs/eng/release-process.rst @ 383b600

Last change on this file since 383b600 was 383b600, checked in by Sebastian Huber <sebastian.huber@…>, on 01/28/22 at 13:58:58

eng: Add rtems-central.git post branch procedures

  • Property mode set to 100644
File size: 14.2 KB
Line 
1.. SPDX-License-Identifier: CC-BY-SA-4.0
2
3.. Copyright (C) 2020 Contemporary Software
4.. Copyright (C) 2020 Chris Johns
5
6.. _Release_Process:
7
8Release Process
9***************
10
11The release process creates an RTEMS release. The process has a number of
12stages that happen before a release can be made, during the creation of the
13release and after the release has been made.
14
15Releases
16========
17
18RTEMS is released as a collection of ready to use source code and built
19documentation. Releases are publicly available on the RTEMS servers under
20https://ftp.rtems.org/pub/rtems/releases.
21
22Releases are group under the major version number as a collection of
23directories consisting of the version number. This is termed a release
24series. A release may also contain release snapshots.
25
26All releases must have a three digit version number and this can be optionally
27followed by a dash character (``-``) and an identifier, e.g. ``5.1.0-acme-1``.
28
29The RTEMS Project reserves releases with only the three digit version number,
30e.g. ``5.1.0``. This identifies an RTEMS Project release.
31
32Release Layout
33--------------
34
35* All released source archives are XZ compressed tar files.
36
37* Top level contains:
38
39:file:`README.txt`:
40    A set of brief release instructions.
41
42:file:`contrib`:
43    Contributed sources. For example the release scripts used to create the
44    release.
45
46:file:`docs`:
47    Compressed documentation build in HTML, Single page HTML and PDF
48    formats. Provide compressed files for each document and a single archive
49    of all the documentation. Provide an SHA512 check sum file.
50
51:file:`rtems-<VERSION>-release-notes.pdf`:
52    RTEMS Release notes document the changes in a release. This is a capture
53    of the Trac report for the release's milestone in PDF format.
54
55:file:`sha512sum.txt`:
56    SHA512 checksum of all files in this directory.
57
58:file:`sources`:
59    All source code referenced by the release.
60
61Release Version Numbering
62-------------------------
63
64The release numbering scheme changed with RTEMS 5.
65
66The master branch has the version N.0.0 with N being the next major release
67number. The release branch in a repository will be just the major number.
68
69The first release of this series will have the version number N.1.0. The first
70bugfix release (minor release) of this series will have the version number
71N.2.0.
72
73The release branch will have the version number N.M.1 with M being the last
74minor release of this series. Tools will use N as the version number and must
75be compatible with all releases and the release branch of the N series.
76
77Examples:
78
79 - ``5.0.0`` is the version number of the development master for the 5 series
80
81 - ``5.1.0`` is the first release of the 5 series
82
83 - ``5.1.1`` is the version number of the 5 series release branch right after
84   the 5.1.0 release until 5.2.0 is released
85
86 - ``5.2.0`` is the first bugfix release of the 5 series
87
88 - ``5.2.1`` is the version number of the 5 series release branch right after
89   the 5.2.0 release until 5.3.0 is released
90
91 - ``6.0.0`` is the version number of the development master for the 6 series
92
93Release Scripts
94----------------
95
96* The release scripts are held in the top level repository
97  https://git.rtems.org/rtems-release.git.
98
99* The scripts are written for FreeBSD and can run on FreeBSD 10 through
100  FreeBSD 12. No other host operating system is supported for the release
101  scripts. Updates are welcome if the changes do not affect the operation on
102  FreeBSD.
103
104* A Python ``virutalenv`` environment is required for a working Sphinx
105  documentation building environment. Follow the procedure in the
106  ``rtems-docs.git`` top level ``README`` file.
107
108* Building a standard release requires you provide the release major number
109  and the release's remaining version string including any additional
110  identifiers:
111
112  .. code-block:: none
113
114     ./rtems-release 5 1.0
115
116  To create a release snapshot:
117
118  .. code-block:: none
119
120    ./rtems-release 5 0.0-m2003
121
122* A 3rd option of a release URL can be provided to create a test or deployable
123  release. The URL is a base path the RSB uses to download the release source
124  files from:
125
126  .. code-block:: none
127
128    ./rtems-release \
129        -u https://ftp.rtems.org/pub/rtems/people/chrisj/releases \
130        5 0.0-m2003-2
131
132* Building the release notes requires the Web Toolkit HTML to PDF converter be
133  installed. The FreeBSD package is ``wkhtmltopdf``.
134
135Release Snapshots
136-----------------
137
138* Release snapshots are only created for the current development version of
139  RTEMS. For example RTEMS 5 snapshot path is :file:`5/5.0.0/5.0.0-m2003`.
140
141* Release snapshots are based on the development sources and may be unstable or
142  not suitable for use in production.
143
144* A release snapshot is created each month and is named as
145  ``<major>/<version>/<version>-<YYMM>`` where ``YY`` is the last two digits of
146  the current year and ``MM`` is the month as a two digit number.
147
148* In the lead up to a release more than one snapshot can be created by
149  appending ``-<count>`` to the snapshot version string where ``<count>`` is
150  incremented starting from ``1``. The first snapshot without a count is
151  considered number ``0``.
152
153* Release snapshots maybe removed from the RTEMS servers at the discretion of
154  the RTEMS project
155
156Release Repositories
157====================
158
159The following are the repositories that a release effects. Any repository
160action is to be performed in the following repositories:
161
162* ``rtems.git``
163
164* ``rtems-central.git``
165
166* ``rtems-docs.git``
167
168* ``rtems-examples.git``
169
170* ``rtems-libbsd.git``
171
172* ``rtems-release.git``
173
174* ``rtems-source-builder.git``
175
176* ``rtems-tools.git``
177
178* ``rtems_waf.git``
179
180Pre-Release Procedure
181=====================
182
183* All tickets must be resolved, closed or moved to a later
184  milestone. Tickets can exist that are specific to the branch and are
185  to be resolved before the first release is made.
186
187* Create release snapshots and post suitable build and test results.
188
189Release Branching
190=================
191
192A release has a release branch in each of the release repositories. A
193release is a created from a release branch. The release branch label
194is the RTEMS major version number.
195
196LibBSD Release Branch
197---------------------
198
199The ``rtems-libbsd.git`` is an exception as it has two active release
200branches. The repository has a release branch based on the ``master``
201like all the release repositories and it can have a FreeBSD version
202specific release branch that is used in the release.
203
204LibBSD runs two branches during it's development cycle. The ``master``
205branch tracks the FreeBSD ``master`` branch. This means LibBSD tracks
206FreeBSD's development. LibBSD also tracks a FreeBSD branch for the
207RTEMS release. For example RTEMS 5 tracks FreeBSD 12 as it's release
208base. This provides functionaly stability to the RTEMS 5 release by
209allowing a control process to track bug fixes in FreeBSD 12.
210
211Pre-Branch Procedure
212--------------------
213
214* All tickets assigned to the release's first milestone must be
215  resolved. Tickets can exist that are specific to the branch and are
216  to be resolved before the first release is made.
217
218* The following BSP must build using the RSB:
219
220  - ``arm/beagleboneblack``
221
222* Check and make sure the RSB kernel, libbsd and tools configurations
223  reference the ``master`` when the branch is made.
224
225  The RSB Git builds reference a specific commit so it is important
226  the relevant configurations are valid.
227
228Branch Procedure
229----------------
230
231* Branch labels are the major number as branch releases increment the minor
232  number. A branch is only created when the first major release is made.
233
234  The commands to set a remote branch for a release in a repository are:
235
236  .. code-block:: none
237
238      git clone <URL>/<REPO> <REPO>
239      cd <REPO>
240      git checkout -b <VERSION> origin/master
241      git push origin <VERSION>
242
243  Example:
244
245  .. code-block:: none
246
247      git clone ssh://chrisj@dispatch.rtems.org/data/git/rtems.git rtems.git
248      cd rtems.git
249      git checkout -b 5 origin/master
250      git push origin 5
251
252* Check and make sure the RSB kernel, libbsd and tools reference the
253  branch commit.
254
255Post-Branch Procedure
256---------------------
257
258#. Create a release page for the next RTEMS release in Trac.
259
260#. Update the releases table. The page link is:
261
262     https://devel.rtems.org/wiki/Release
263
264   Update the table adding the new development release to the top
265   moving down the previous releases.
266
267   Label the new release branch as "Releasing". The documentation link
268   is left pointing to ``master`` until the release is made and the
269   documentation is installed on the RTEMS Documentation web site.
270
271#. Update the release table in the front page of the Trac Wiki. The
272   page link is:
273
274     https://devel.rtems.org/wiki/
275
276#. Add the milestones for the new development branch. The Trac page
277   is:
278
279   .. code-block:: none
280
281       = 6.1 (open)
282
283       == Statistics
284
285       ||   '''Total'''||[[TicketQuery(milestone=6.1,count)]]                                      ||
286       ||         Fixed||[[TicketQuery(status=closed&milestone=6.1,resolution=fixed,count,)]]      ||
287       ||       Invalid||[[TicketQuery(status=closed&milestone=6.1,resolution=invalid,count,)]]    ||
288       ||  Works for me||[[TicketQuery(status=closed&milestone=6.1,resolution=worksforme,count,)]] ||
289       ||     Duplicate||[[TicketQuery(status=closed&milestone=6.1,resolution=duplicate,count,)]]  ||
290       ||     Won't fix||[[TicketQuery(status=closed&milestone=6.1,resolution=wontfix,count,)]]    ||
291
292       == Distribution
293       [[TicketQuery(milestone=6.1&group=type,format=progress)]]
294
295       == Summary
296       [[TicketQuery(milestone=6.1)]]
297
298       == Details
299       [[TicketQuery(col=id|time|resolution|component|reporter|owner|changetime,status=closed&milestone=6.1,rows=summary|description,table)]]
300
301   Replace ``6.1`` with the required milestone.
302
303#. Create the RC1 release candidate with the source as close the
304   branch point as possible.
305
306#. Create a ticket to the clean the RSB for the release. The RSB's
307   ``master`` branch carries a number of older configurations and new
308   release configurations. These can be confusing to a new user and
309   add no value to a released RSB. For example leaving RTEMS 6 tool
310   building configurations in the RTEMS 5 release.
311
312#. Check out the release branch of ``rtems-central.git``.  Change all Git
313   submodules to reference commits of the corresponding release branch.  Run
314   ``./spec2modules.py``.  Inspect all Git submodules for changes.  If there
315   are locally modified files, then there are two options.  Firstly, integrate
316   the changes in the release branches.  Afterwards update the Git submodule
317   commit.  Secondly, change the specification so that a particular change is
318   not made.  Make sure that there are no changes after this procedure.
319
320Post-Branch Version Number Updates
321^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
322
323After the release repositored have been branched the ``master`` branch
324has to have the major version number updated. The follow is a list of
325the needed changes.
326
327#. RTEMS requires the following files be changed:
328
329    * :file:`Doxyfile`: Update ``PROJECT_NUMBER``.
330
331    * :file:`rtems-bsps`: Update ``rtems_version``.
332
333    * :file:`spec/build/cpukit/optvermaj.yml`: Update ``set-value``.
334
335    * :file:`spec/build/cpukit/optvermin.yml`: Update ``set-value``.
336
337    * :file:`spec/build/cpukit/optverrev.yml`: Update ``set-value``.
338
339    * :file:`wscript`: Update ``default_prefix``.
340
341#. RTEMS Documentation the following files be changed:
342
343    * :file:`wscript`: Update ``rtems_major_version``.
344
345#. RSB requires the following files be changed:
346
347    * :file:`source-builder/sb/version.py`: Update ``_version``.
348
349#. RTEMS Tools requires the following files be changed:
350
351    * :file:`config/rtems-version.ini`: Update ``revision``.
352
353    * :file:`tester/rtems/version.cfg`: Update ``rtems_version``.
354
355#. ``rtems-libbsd`` requires the following files and branches be changed:
356
357    * :file:`README.md`: Update ``Branches`` section.
358
359    * :file:`wscript`: Update ``rtems_version``.
360
361    * Create a new branch for tracking the FreeBSD stable version, for example
362      ``6-freebsd-12``.
363
364#. ``rtems-examples`` requires the following files be changed:
365
366    * :file:`wscript`: Update ``rtems_version``.
367
368Release Procedure
369=================
370
371The release procedure can be performed on any FreeBSD machine and uploaded to
372the RTEMS FTP server. You will need ssh access to the RTEMS server
373``dispatch.rtems.org`` and suitable permissions to write into the FTP release
374path on the RTEMS server.
375
376#. The release process starts by branching the repositories. To branch
377   run the script:
378
379   .. code-block:: none
380
381       ./rtems-release-branch [-p] <USER> <VERSION> <REVISION>
382
383   Example:
384
385   .. code-block:: none
386
387       cd
388       mkdir -p development/rtems/releases
389       cd development/rtems/releases
390       git clone git://git.rtems.org/rtems-release.git rtems-release.git
391       cd rtems-release.git
392       ./rtems-release-branch -p chrisj 5
393
394   You need to have suitable commit access to the repositories.
395
396#. To create the RTEMS release run the release script:
397
398   .. code-block:: none
399
400       ./rtems-release <VERSION> <REVISION>
401
402   Example:
403
404   .. code-block:: none
405
406       ./rtems-release 5 1.0
407
408#. Copy the release to the RTEMS FTP server:
409
410   .. code-block:: none
411
412       ssh <user>@dispatch.rtems.org mkdir -p /data/ftp/pub/rtems/releases/<VERSION>
413       scp -r <VERSION>.<REVISION> <user>@dispatch.rtems.org:/data/ftp/pub/rtems/releases/<VERSION>/.
414
415   Example:
416
417   .. code-block:: none
418
419       ssh chrisj@dispatch.rtems.org mkdir -p /data/ftp/pub/rtems/releases/5
420       scp -r 5.1.0 chrisj@dispatch.rtems.org:/data/ftp/pub/rtems/releases/5/.
421
422#. Verify the release has been uploaded by checking the link:
423
424   https://ftp.rtems.org/pub/rtems/releases/<VERSION>/<VERSION>.<REVISION>
425
426#. Tag the release repositories with the following command:
427
428   .. code-block:: none
429
430       git checkout -b origin/<VERSION>
431       git tag <TAG>
432       git push origin <TAG>
433
434   Example:
435
436   .. code-block:: none
437
438      git clone ssh://chrisj@dispatch.rtems.org/data/git/rtems.git rtems.git
439      cd rtems.git
440      git checkout -b origin/5
441      git tag 5.1.0
442      git push origin 5.1.0
443
444Post-Release Procedure
445======================
446
447The following procedures are performed after a release has been created.
448
449#. Update the release to the RTEMS servers:
450
451   .. code-block:: none
452
453     rsync --rsh=ssh -arv 5.1.0 chrisj@dispatch.rtems.org:/data/ftp/pub/rtems/releases/5/.
454
455#. Test a build of the ``beagleboneblack`` BSP.
Note: See TracBrowser for help on using the repository browser.