Ichthyostega
bd48b17f70
Hereby I introduce a ''Development Status'' page, where the current phase of the release cycle can be marked and similar status information is published. This page also includes the Changelog (from the file NEWS). Since updates must be checked into Git and then pushed to our website, such status marks are documented in the history. Some notes regarding the phases of the Release cycle were also added to the Release checklist. + some additional links resources and documentation tweaks
150 lines
5.5 KiB
Text
150 lines
5.5 KiB
Text
Release preparation
|
|
===================
|
|
:Author: Ichthyo
|
|
:Date: Nov 2025
|
|
|
|
We have nothing to show yet and don't provide public releases --
|
|
but we ought to rehearse and practice the release process.
|
|
This document contains some hints and a checklist of steps
|
|
to perform for a proper release.
|
|
|
|
IMPORTANT: Lumiera uses link:{ldoc}/technical/code/GitBranching.html[Git-flow]
|
|
for the organisation of release branches and tags. Releases are still
|
|
considered ``experimental'' and happen infrequently, so that a full
|
|
automation of these steps was not yet considered. So please be
|
|
sure to adhere to the established conventions.
|
|
|
|
.Each Release has three phases
|
|
- Development
|
|
- Convergence
|
|
- Preparation
|
|
|
|
During the »convergence phase«, all participants must prioritise code stability.
|
|
After the »release cut«, development can resume freely on branch `integration`,
|
|
while »release preparation« ensues on the _release branch_. The
|
|
published documentation branch and the website will follow suit on the
|
|
release branch. Please mark the current phase on the
|
|
link:{ldoc}/devel/Status.html[Development Status] page.
|
|
|
|
|
|
Steps to perform for a release
|
|
------------------------------
|
|
|
|
. Pre-Release _»convergence phase«_
|
|
|
|
- care for code stability and refrain from breaking changes
|
|
- announce and mark »convergence« on the link:{ldoc}/devel/Status.html[Status] page.
|
|
- verify that the _current version number_ is already set to
|
|
the version number expected for the upcoming release, yet
|
|
decorated with the `~dev` suffix -- if it turns out that
|
|
the upcoming release shall make a _major version bump,_
|
|
then the expected version must be set *now*. Once
|
|
the release branch has been forked, the version
|
|
must not be changed any more.
|
|
|
|
. Release cut
|
|
|
|
- create the _Release Branch_ with name `rel/#.#.#`
|
|
- after that fork, immediately perform the *version bump*
|
|
on branch `integration`
|
|
+
|
|
--
|
|
** use the Script: `admin/buildVersion --bump=maj|min|rev --suffix=dev`
|
|
** typical usage
|
|
----
|
|
admin/setVersion `admin/buildVersion.py --bump -s dev`
|
|
----
|
|
--
|
|
+
|
|
[IMPORTANT]
|
|
what you set here *must* be the next version _after the release_
|
|
|
|
|
|
. Release preparation: clean-up obsolete information
|
|
|
|
- Debian package descriptions
|
|
- Build-Tutorial
|
|
|
|
* building from source
|
|
* building the debian way
|
|
* contributing
|
|
|
|
- technical/build/Dependencies
|
|
- check and update *Release-Notes*
|
|
|
|
* check that 'README' is up-to-date
|
|
* add a new summary entry into 'NEWS'
|
|
* check the 'AUTHORS' info
|
|
|
|
** ensure that the copyright time span
|
|
mentioned for each relevant contributor
|
|
is correct and possibly spans the current year
|
|
** it is _crucial_ (legally relevant) that at least
|
|
the person preparing the release and thus acting as
|
|
publisher is mentioned here with the _current year_
|
|
** ensure that a correct summary is presented in the "About"
|
|
dialog of the GTK-UI. The necessary config is currently (2025)
|
|
maintained in the file 'setup.ini' (the info displayed here
|
|
should be the list of all _significant contributors_ and
|
|
cover the whole time span from 2007 until _NOW_)
|
|
|
|
* check that the 'LICENSE' file mentions the core authors,
|
|
again with the correct copyright time span
|
|
|
|
. Test phase
|
|
|
|
- even while we have automated tests, be sure at least to do
|
|
some ``smoke test''. Ideally have _someone else_ use the new
|
|
version on a real-world project.
|
|
- depending on the circumstances, possibly set a _release candidate_ version, +
|
|
using a `--suffix=rc.#`
|
|
|
|
. Publish the Release
|
|
|
|
- merge the release branch into `master`
|
|
- set the version again, this time without any `--suffix`
|
|
- amend the merge commit to _include that final version_
|
|
- set the *Release Tag* in accordance with the
|
|
link:{ldoc}/devel/rfc/VersionNumberScheme.html[Version-Number scheme].
|
|
- fast forward also the _release branch_ to sit at that tag
|
|
- *publish* by pushing into git://git/lumiera/org/LUMIERA
|
|
|
|
** the latest state of `master`
|
|
** the release tag
|
|
|
|
. Back-Merge: +
|
|
**never loose any release work**
|
|
|
|
- `git checkout integration`
|
|
- `git merge rel/#.#.#`
|
|
- work through possible merge conflicts and resolve them
|
|
- conflicts on the version number *must* be resolved in favour
|
|
of the _next version number_ -- you can perform that as an
|
|
extra step, _after the merge_ is otherwise complete:
|
|
`admin/buildVersion --bump ... --suffix=dev` (and then
|
|
amend the merge!)
|
|
- *delete* the release-branch
|
|
- push this delete to the public repos, incl the main repo!
|
|
|
|
. Packaging...
|
|
|
|
- merge release-tag -> branch `deb`
|
|
- verify the package description
|
|
- have a look at manpages and similar packaging documents; +
|
|
notably look into 'debian/README.Debian', since we deliver
|
|
that instead of 'README' for the Debian users, since they
|
|
do not need instructions how to build the software...
|
|
- update 'debian/control' to reflect current version dependencies
|
|
- have a look into 'debian/rules' (e.g. build flags and similar)
|
|
- update 'debian/copyright' to reflect authors and copyright!
|
|
|
|
. Delivery
|
|
|
|
- use whatever infrastructure is available to build packages.
|
|
- verify packages can be installed on a pristine VM / Container
|
|
- upload packages to debian depot or commit them to PPAs
|
|
- clean-up and discard obsoleted old distributions and packages
|
|
|
|
. Close the **Release Ticket**
|
|
and update the link:{ldoc}/devel/Status.html[Status] page.
|
|
|