Content
Release Process
Release Process
Release Types
The OpenProject world distinguishes three kinds of releases:
-
Stable Release: Currently supported version of the OpenProject software
meant for production environments. -
Hotfix Release: Update of the current stable release of the OpenProject
software which includes at least one critical bug. -
Sprint Release: Snapshot of the current development of the OpenProject
software. This release type is typically ahead of the stable release in regard to
the included feature set and critical/uncritical bug fixes. However, this Release
type is still in development and therefore not meant for production environments.
Distribution
- The OpenProject software and plugins developed by the OpenProject Foundation
itself are maintained on Github. - Releases exist as snapshots (tags) of different development trees (branches)
at a specific point in time.
Explanatory note:
Due to the fact that the OpenProject Foundation provides releases in the form of
the source code itself all release types are fully self-contained. This means that
a hotfix release for example does not only include parts of the software which are
going to be fixed by the hotfix release itself. Instead it includes the latest
stable release and the fixes it was build for (i.e. we don’t release patches seperately).
Release Notes
Stable and Hotfix Releases
- You will find an overview of all the stable and hotfix releases, the history of changes(changelog)here
- For the major releases the release notes include the feature set overview.
Sprint Releases
- Due to the fact that this release type is not recommended for production
environments release notes are not available.
Release cycles
Stable Release
- The OpenProject Foundation releases four Stable Releases per year.
- The Release plan is tracked via the project timeline
Hotfix Release
- Hotfix releases follow no predefined release plan.
- News article will be used to inform the community about hotfix releases.
- As soon as a bug is declared to be critical and there has to be an emergency
update to currently supported stable releases a hotfix release will be prepared.
However, the criteria which define a bug to be critical depend on several
conditions which make it almost impossible to give a clear definition of what
constitutes a critical bug.
Sprint Release
- At the end of each sprint (typically every three weeks) an end of the sprint release
will be created.
Versioning and Tags
General considerations
- See the Roadmap for the overview of the current stable release version and upcoming stable releases
- The concrete version of the upcoming stable release is determined as part of the
quarterly mid term planning by the OpenProject Foundation. - Releases are defined by a version (number) which exists as tags on predefined
development trees (see the branches github). - Since Stable Release 3.0.8 all plugins maintained by the OpenProject Foundation
have the same release cycle and the same version as the OpenProject software
itself (typically called OpenProject core or just core). - The version of plugins indicate the compatibility with the core. The OpenProject
Foundation will ensure this via continuous integration testing.
Versioning in Detail
- OpenProject follows the idea of Semantic Versioning.
- Therefore the version is a composition of three digits in the format of e.g.
3.0.11 and can be summarised as followed:
**** MAJOR version when you make incompatible API changes,
**** MINOR version when you add functionality in a backwards-compatible manner, and
**** PATCH version when you make backwards-compatible bug fixes.
- Since the Stable Release 3.0.8 this idea only applies by considering the
OpenProject core and all plugins maintained by the OpenProject Foundation
as one piece of software.
—
Side Note: Keeping Core and Plugin Versions in lockstep
- Due to the fact that plugins inherit their version from the core of the
OpenProject software and vice versa there are some implications to mention.- Since this only applies to the versions starting at version 3.0.8 (core) there are plugins
which have surpassed this version in the past. The most noticeable is the costs
plugin which version was set back from version 5.0.4 to 3.0.8.- Furthermore it is likely that the version may change for a lot of plugins or the
core itself, although the source code of these software parts did not change at
all. The reason for that is the described inheritance of versions.What is the benefit then?
- At the current state the OpenProject software architecture lacks on a defined
interface for plugins. Therefore a lot of plugins overwrite the OpenProject core
in an undesirable manner.- With more and more plugins available this is a problem because one plugin can
break the whole software, even those parts, which the plugin itself is not responsible for.- This is a huge problem when it comes to tests because that means at least in
theory all the combination (versions) of plugins used have to be tested.
Furthermore combinations that work as expected have to be tracked and this
documentation has to be updated whenever new versions of a plugins are developed.
This is a very serious issue.
- To address these two issues it was decided to keep the version of the core in
lockstep with the plugins. By doing so the testing of the OpenProject core
with different combinations of plugins can be reduced to a minimum. Per
definition the last stable core has to be working with the last stable
plugins all sharing the same version. A documentation of which plugin and core
version works together becomes obsolete because it is defined by convention.
- This method seems to be the most clear and most straight forward approach for now
and the near future. It also has the advantage that plugin development and core
development have to be more aligned then ever before.- The OpenProject Foundation is aware that this solution should only be temporary
and therefore should be replaced as soon as the described architectural
restrictions of handling plugins are resolved.—
Branches and Tags on Github
- There are two important branches in regard to the release process:
**** dev: development of future stable releases
**** release/X.Y: currently supported stable release
- Tags on these two branches refer either to sprint releases (dev) or stable
respectively hotfix releases (release/X.Y).
History of Changes
- As of OpenProject Stable Release 3.0.8 all changes made to the OpenProject
software are documented via work packages on
openproject.org - The Roadmap view
gives a corresponding overview. - To prevent inconsistencies and avoid redundant work there is there is no
additional change log in the source code.
Support of Releases
- The last two stable releases are maintained.
- That is why it is strongly recommended to update to a new stable release as soon as
possible to have a supported version installed. Time available for doing the
update is defined by the release cycle (see above).