Project

General

Profile

LArSoft release naming policy » History » Version 3

« Previous - Version 3/9 (diff) - Next » - Current version
Erica Snider, 03/19/2015 01:56 AM


LArSoft release naming and retention policy

These policies were approved at the May 6 LArSoft Librarian's Meeting: https://indico.fnal.gov/categoryDisplay.py?categId=405

  • All release versions will use the following numbering convention: vMM_mm_pp
    • MM = major number, mm = minor number, pp = patch number
    • Releases that require a fork in order to fix a problem will have a suffix added after the patch number
      • A fork is required if and only if the release to be patched is not the latest release available
  • Version numbers will be incremented according to the following policy:
    • The patch number will increment for routine weekly integration releases or bug fixes
    • The minor number will increment when new features or changes in functionality are introduced
      • New data members added to existing data products, or extensions to existing user-facing interfaces will require that the minor number be changed.
      • Interface changes that can be considered
    • The major number will be incremented for changes that break backwards compatibility, or that involve changes to important components of the infrastructure. For example:
      • Changes to data products that are not backwards compatible
      • Changes to user-level interfaces (i.e., interface changes that are not backwards compatible and cannot be considered to be part of an implementation)
      • Changes to any of the major external dependencies (e.g., root, gcc)
  • Policies for production releases differ from those of other releases in the following ways:
    • Production releases will be announced to the LArSoft collaboration. The determination of what releases qualify as "production" will be made by the experiments. The affirmation of a single experiment is sufficient to declare a release as "production".
    • Production releases will be retained indefinitely. Removal of production releases will be coordinated with the experiment(s) that requested the production status.
    • Each production release will carry one or more common tags across all constituent repositories indicating the larsoft version and the experiment that requested the production status. More than one tag will be used in the case that the release is declared as "production" by more than one experiment.