Release management

From OTBWiki
Revision as of 18:30, 19 November 2010 by WikiSysop (Talk | contribs) (Reverted edits by Ulofyvy (Talk); changed back to last version by Christop)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Organize the reflexion around the philosophy of release management of OTB and Monteverdi. The Orfeo Toolbox project is composed by:

  • The core library : Sets of image processing algorithm
  • OTB Applications: collection of standalone applications that were intended to demonstrate the capabilities of the library
  • Monteverdi : Application which allow to construct an interactive treatment based on OTB functionalities

The goal is to define a procedure to ensure a safe management of dependency between OTB and Monteverdi. It is also necessary to plan the convergence (or not) of Monteverdi and OTB-Applications.


There is a strong coupling between Monteverdi and OTB versions. The development of Monteverdi often involved significant modifications in the library. Ideally, OTB should be preserve backward compatibility (eg. Montervedi X.Y require at least OTB W.Z but should work with all OTB version after W.Z). Unfortunately, OTB interfaces are not stable enough to provide this property.

We want to have a clear hierarchy between OTB and Monteverdi. OTB team have to choose an revision control procedure which allow to tag a new version of Monteverdi which will correspond to a specific version of the OTB library. If someone download Monteverdi source code, he have to know with which version of OTB it'll work.

Possible solutions

Include Monteverdi in OTB

  • YES: Allow to trace the dependency between Monteverdi and OTB.
  • NO: Don't feet the need;Loose the paradigm of otb=parent and monteverdi=module; Can't make asynchronous release of the core library and the module Monteverdi. Being able to use OTB as a base for specific applications is an important property that should not be lost by forcing Monteverdi in. OTB and Monteverdi addresses two different problems and do not target the same public.

Concept of sub repository

Treat a collection of repositories as a group This is a experimental feature in Mercurial 1.3 [[1]]

This can address the problem of source management between the 2 projects.

  • In our case:
    • main repository: OTB??
    • nested repository : Monteverdi??

OTB Release policy

The primary question is about the new policy of release planning (OTB and Monteverdi). Release management scenario => Softwares management solution

  • Nothing change: Plan regular OTB release (Monteverdi release in the same time)
    • YES: nothing to do...
    • NO: we don't want to synchronize OTB and Monteverdi release
  • Asynchronous release

Version numbering issue

If the release are synchronized, the numbering system could be common: eg. OTB 3.2 working with Monteverdi 3.2 Another system of number could let the release date appear: eg. OTB 2009.12 for a december release.


  • Software Release Trains

[] A Release Train is the technique of planning software releases on regular or cyclic time period, for example, the last day of every quarter, or every 9 weeks, etc. The "train" metaphor of a release train is likely based on the concept of railroad train schedules (planned arrival and departure times) and that trains carry multiple types of rolling stock (different types of projects are included in a release).

Planning and technical solution


  • 15/12/09: Monteverdi Beta
  • 15/02/10: OTB 3.2 Release
  • Regular release of OTB or Monteverdi

Technical solution