Top Menu

Jump to content
Home
    • Projects
    • Work packages
    • News
    • Getting started
    • Introduction video
      Welcome to OpenProject Community

      Get an overview

      Get a quick overview of project management and team collaboration with OpenProject. You can restart this video from the help menu.
    • Help and support
    • User guides
    • Videos
    • Shortcuts
    • Community forum
    • Professional support
    • Additional resources
    • Data privacy and security policy
    • Digital accessibility (DE)
    • OpenProject website
    • Security alerts / Newsletter
    • OpenProject blog
    • Release notes
    • Report a bug
    • Development roadmap
    • Add and edit translations
    • API documentation
  • Sign in
      Forgot your password?
      Create a new account

      or sign in with your existing account

      Google

Side Menu

  • Overview
  • Activity
  • Roadmap
  • Work packages
  • Calendars
  • Team planners
  • Boards
  • Forums
  • Wiki
    • Table of contents
      • Expanded. Click to collapseCollapsed. Click to showDeveloper
        • Hierarchy leafAccessibility Checklist
        • Hierarchy leafCode Review Guidelines
        • Expanded. Click to collapseCollapsed. Click to showContribution
          • Hierarchy leafGit Workflow
          • Hierarchy leafTranslations
        • Expanded. Click to collapseCollapsed. Click to showDeveloping Plugins
          • Hierarchy leafDeveloping an OmniAuth Authentication Plugin
        • Hierarchy leafRelease Process
        • Hierarchy leafReport a bug
        • Hierarchy leafSecurity
        • Hierarchy leafSetting up an OpenLDAP server for testing
        • Hierarchy leafTheme Features
      • Hierarchy leafDownload
      • Expanded. Click to collapseCollapsed. Click to showFeature tour
        • Hierarchy leafRelease Notes OpenProject 30
        • Expanded. Click to collapseCollapsed. Click to showRelease Notes OpenProject 30 - Overview
          • Hierarchy leafGlossary
          • Hierarchy leafRelease Notes - Accessibility
          • Hierarchy leafRelease Notes - Accessibility changes
          • Hierarchy leafRelease Notes - Add work package queries as menu items to sidebar
          • Hierarchy leafRelease Notes - Copy projects based on Templates
          • Hierarchy leafRelease Notes - Design changes
          • Hierarchy leafRelease Notes - Fixed Bugs
          • Hierarchy leafRelease Notes - Keyboard Shortcuts
          • Hierarchy leafRelease Notes - Project settings
          • Hierarchy leafRelease Notes - Ruby&Rails Update
          • Hierarchy leafRelease Notes - Security
          • Hierarchy leafRelease Notes - Timelines
          • Hierarchy leafRelease Notes - Work packages
      • Hierarchy leafHowto create animated gifs
      • Hierarchy leafMigration Squashing
      • Hierarchy leafMod security
      • Hierarchy leafNew work package page
      • Hierarchy leafOP3 to OP4 Debian upgrade
      • Hierarchy leafOP4 Ubuntu1404 Stable with MySQL in production
      • Hierarchy leafOpenProject 40 Development Setup
      • Expanded. Click to collapseCollapsed. Click to showOpenProject Foundation
        • Hierarchy leafBoards
        • Hierarchy leafMembers
        • Hierarchy leafOPF-Meetings
        • Hierarchy leafStatutes
      • Expanded. Click to collapseCollapsed. Click to showRelease Notes
        • Hierarchy leafOpenProject released on Bitnami
      • Expanded. Click to collapseCollapsed. Click to showRelease Notes OpenProject 40 - Overview
        • Hierarchy leafRelease Notes OpenProject 40 - Accessibility improvements
        • Hierarchy leafRelease Notes OpenProject 40 - Column header functions in work package table
        • Hierarchy leafRelease Notes OpenProject 40 - Improved Design
        • Hierarchy leafRelease Notes OpenProject 40 - Integrated query title on work package page
        • Hierarchy leafRelease Notes OpenProject 40 - Integrated toolbar on work package page
        • Hierarchy leafRelease Notes OpenProject 40 - OmniAuth integration for OpenProject
        • Hierarchy leafRelease Notes OpenProject 40 - Work package details pane
      • Expanded. Click to collapseCollapsed. Click to showSecurity and privacy
        • Hierarchy leafFAQ
      • Expanded. Click to collapseCollapsed. Click to showSupport
        • Expanded. Click to collapseCollapsed. Click to showDownload and Installation
          • Hierarchy leafInstallation MacOS
          • Expanded. Click to collapseCollapsed. Click to showInstallation OpenProject 3 0
            • Hierarchy leafDebian Stable with MySQL in production
            • Hierarchy leafInstallation Ubuntu
            • Hierarchy leafInstallation Windows
            • Hierarchy leafInstallation on Centos 65 x64 with Apache and PostgreSQL 93
          • Expanded. Click to collapseCollapsed. Click to showInstallation OpenProject 40
            • Hierarchy leafOP4 Debian Stable with MySQL in production
          • Expanded. Click to collapseCollapsed. Click to showMigration paths
            • Hierarchy leafFrom Chilliproject to OpenProject
            • Hierarchy leafMigration 15 to 30
            • Hierarchy leafMigration 24 to 30
            • Hierarchy leafMigration Redmine 2x › OpenProject 30
            • Hierarchy leafOpenProject 3 Migration
          • Hierarchy leafOpenProject 40
        • Expanded. Click to collapseCollapsed. Click to showNews
          • Hierarchy leafNew OpenProject Translations Plugin
          • Hierarchy leafNew Plugin on OpenProjectorg Local Avatars
          • Hierarchy leafNew design for OpenProject
          • Hierarchy leafNews Accessibility workshop for OpenProject
          • Hierarchy leafNews Glossary for OpenProject
          • Hierarchy leafNews Heartbleed fixed
          • Hierarchy leafNews Icon Fonts
          • Hierarchy leafNews OpenProject 30 Release
          • Hierarchy leafNews Release GitHub Integration Plugin
          • Hierarchy leafNews Success Story Deutsche Telekom
          • Hierarchy leafNews Timelines
          • Hierarchy leafOpenProject 3013 released
          • Hierarchy leafOpenProject 3017 released
          • Hierarchy leafOpenProject 40 released
          • Hierarchy leafOpenProject 40 will be coming soon
          • Hierarchy leafOpenProject 405 released
          • Hierarchy leafOpenProject and pkgrio
          • Hierarchy leafOpenProject news moved to a new blog
          • Hierarchy leafOpenProjectBitnami
          • Hierarchy leafPackager version with plugins released ("Community edition")
          • Hierarchy leafRegistration OpenProject-Foundation
          • Hierarchy leafRelease OpenProject AuthPlugins
          • Hierarchy leafUpdates on OpenProject
          • Hierarchy leafWe need your feedback for the the new fullscreen view for work packages
        • Hierarchy leafOpenProject Plug-Ins
      • Hierarchy leafWiki
You are here:
  • Developer
  • Release Process

Content

Release Process

  • More
    • Table of contents

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).
Loading...