Project

General

Profile

LArSoft release naming policy » History » Version 1

Erica Snider, 09/02/2014 12:40 PM

1 1 Erica Snider
h1. LArSoft release naming policy
2 1 Erica Snider
3 1 Erica Snider
* All release versions will use the following numbering convention: vMM_mm_pp
4 1 Erica Snider
** MM = major number, mm = minor number, pp = patch number
5 1 Erica Snider
** Releases that require a fork in order to fix a problem will have a suffix added after the patch number
6 1 Erica Snider
*** A fork is required if and only if the release to be patched is not the latest release available
7 1 Erica Snider
* Version numbers will be incremented according to the following policy:
8 1 Erica Snider
** The patch number will increment for routine weekly integration releases or bug fixes
9 1 Erica Snider
** The minor number will increment when new features or changes in functionality are introduced
10 1 Erica Snider
*** New data members added to existing data products, or extensions to existing user-facing interfaces will require that the minor number be changed. 
11 1 Erica Snider
*** Interface changes that can be considered 
12 1 Erica Snider
** The major number will be incremented for changes that break backwards compatibility, or that involve changes to important components of the infrastructure. For example:
13 1 Erica Snider
*** Changes to data products that are not backwards compatible
14 1 Erica Snider
*** Changes to user-level interfaces (i.e., interface changes that are not backwards compatible and cannot be considered to be part of an implementation)
15 1 Erica Snider
*** Changes to any of the major external dependencies (e.g., root, gcc)
16 1 Erica Snider
17 1 Erica Snider
* Policies for production releases differ from those of other releases in the following ways:
18 1 Erica Snider
** 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".
19 1 Erica Snider
** Production releases will be retained indefinitely. Removal of production releases will be coordinated with the experiment(s) that requested the production status.
20 1 Erica Snider
** 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.