Skip to content

Release Management

Jump to bottom Edit New page
Beat Küng edited this page Jul 16, 2012 · 3 revisions

Table of Contents

Version numbers

The version string of the Oscar framework is composed of three parts: 

 v<MAJOR>.<MINOR>-p<PATCH>

e.g. 

 v1.3-p1
  • : Changes to this part of the version number indicate a significant rework of the framework source tree, which breaks backwards compatibility.
  • : Changes to this part of the version number indicate that additional features are available that enhance existing functionality. Existing applications developed off an older Minor version of the source tree should still be compatible.
  • : Changes to this part of the version number indicate bug fixes, which do not change or enhance the existing functionality at all, but provide a fix to existing code.

Internal development and release process

The responsibility for keeping the source code clean and consistent lies with the developers and this section defines the rules required for a smooth development process and a good end-user experience.

Branches

  • 'master': The 'master' branch contains the (untested) head of development. Development can be done on personal branches but is always merged with the 'master' branch.
  • 'release': The 'release' branch is the default branch the end-user base pulls from. Therefore, only tested code should end up on the 'release' branch. The 'release' branch always points to the latest released minor version.
  • Minor-version branches: For every MINOR version of the framework there exists a Minor-version branch. There is no development done on this branch. This patch is only updated to incorporate bug fixes to existing features.

Guidelines

The following section provides a manual and checklists what to do for certain situations in the development process.

Start of development of a new feature/feature group/module

  • If the complexity of the problem is low and the desired functionality can be achieved within two or three commits you may work directly on the 'master' branch. For more extensive features, create your own branch and merge it back after you are done.
  • If your feature breaks compatibility with existing applications, develop it on a separate branch and do not merge it back to 'master'; it will be assigned a new MAJOR number when it is released.

End of development of a new feature/feature group/module

  • Test your code as thoroughly as possible.
  • Document the usage of your new feature in this wiki by adding a small example under the respective module.
  • Add your feature to the Changelog

Commit/Merge to 'master' branch

  • The head of the 'master' branch must always compile for all targets and not break any existing applications that use the provided functionality in the intended way. The developer is responsible to ensure these two preconditions.
  • Make sure to provide a descriptive commit message with the commit.

Apply bug fix

  • Test your bug fix and commit it to the 'master' branch
  • Also apply (cherry-pick) the bug fix to the current Minor-version branch.
  • Create a new tag by incrementing the patch level of the last release and make it available to the public. Describe the applied bug-fix in the HISTORY file during tagging with the do-tag script.
  • Update all bundled applications, that include the framework as a submodule and were affected by the bug, to use the new release.
  • Update the version string in the Downloads page in the wiki

Release new Minor version

New Minor versions of the framework are released regularly or exceptionally on an on-demand basis, i.e. if there is an important application requiring a new feature going to be released at the same time. A new release and the features that make part of it are always discussed in the team beforehand.

  • Test the current HEAD of 'master' to compile and work together with all bundled applications, currently:
    • app-template
    • basic-template
    • web-view
    • ...
  • Summarize all the features since the last minor release under a paragraph for the new version number
  • Tag the tested commit on the 'master' branch with the new version number. For this, use the do-tag script and list all new features since the last minor version change in the HISTORY file when asked.
  • Create a new Minor-version branch with the name of the new version and let it point to the tagged commit.
  • Point the 'release' branch at the newly tagged commit.
  • Update all bundled applications that include the framework as a submodule, to use the new framework release.
  • Create a new blog post on this site, describing the new features and changes of the framework.
  • Update the Downloads page in the wiki by adding your new version

Release new Major version

Add a custom footer
Add a custom sidebar
Clone this wiki locally