Project

General

Profile

LArSoft release naming policy » History » Version 4

Erica Snider, 03/19/2015 02:34 AM

1 3 Erica Snider
h1. LArSoft release naming and retention policy
2 1 Erica Snider
3 2 Erica Snider
These policies were approved at the May 6 LArSoft Librarian's Meeting:  https://indico.fnal.gov/categoryDisplay.py?categId=405
4 2 Erica Snider
5 4 Erica Snider
h2. Release naming policies
6 4 Erica Snider
7 1 Erica Snider
* All release versions will use the following numbering convention: vMM_mm_pp
8 1 Erica Snider
** MM = major number, mm = minor number, pp = patch number
9 1 Erica Snider
** Releases that require a fork in order to fix a problem will have a suffix added after the patch number
10 1 Erica Snider
*** A fork is required if and only if the release to be patched is not the latest release available
11 4 Erica Snider
** [The following item is approved on a case-by-case basis at a LArSoft Coordination Meeting] A release can be declared as a "production release candidate", in which case it will have major, minor and patch numbers of the target production release, but with the suffix "_rcN" appended, where N = 1, 2,...
12 1 Erica Snider
* Version numbers will be incremented according to the following policy:
13 1 Erica Snider
** The patch number will increment for routine weekly integration releases or bug fixes
14 1 Erica Snider
** The minor number will increment when new features or changes in functionality are introduced
15 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. 
16 1 Erica Snider
*** Interface changes that can be considered 
17 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:
18 1 Erica Snider
*** Changes to data products that are not backwards compatible
19 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)
20 1 Erica Snider
*** Changes to any of the major external dependencies (e.g., root, gcc)
21 1 Erica Snider
22 4 Erica Snider
23 4 Erica Snider
h2. Release retention policies
24 4 Erica Snider
25 4 Erica Snider
* Releases are categorized into three classes for the purposes of retention policy
26 4 Erica Snider
** Production
27 4 Erica Snider
** Integration (sometimes referred to as "weekly")
28 4 Erica Snider
** Nightly
29 4 Erica Snider
30 4 Erica Snider
31 4 Erica Snider
* Retention policy for production releases
32 4 Erica Snider
** Production releases will announced as such to the LArSoft community and identified on the [[LArSoft release list]] page. 
33 4 Erica Snider
*** The determination of what releases qualify as "production" will be made by the experiments. 
34 4 Erica Snider
*** The affirmation of a single experiment is sufficient to declare a release as "production".
35 4 Erica Snider
** Production releases will be retained indefinitely. 
36 4 Erica Snider
*** Removal of production releases will be coordinated with the experiment(s) that requested the production status.
37 4 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. 
38 4 Erica Snider
*** More than one tag will be used in the case that the release is declared as "production" by more than one experiment.
39 4 Erica Snider
40 4 Erica Snider
* Retention policy for integration releases
41 4 Erica Snider
** Unless otherwise specified, a tagged release will be considered as an "integration" release.
42 4 Erica Snider
*** The purpose of these releases is (a) to provide a code base for development that is stable yet close to the head of some development branch, or (b) to test a particular set of features or changes integrated into a specific body of code.
43 4 Erica Snider
*** A release used for (b) will sometimes be referred to as a "production pre-release" or a "production release candidate". In all cases, they will be retained according to the policy for any other integration release.
44 4 Erica Snider
** Integration releases will be deleted as space is needed
45 4 Erica Snider
*** An announcement will be made to the "larsoft" email list at least one week in advance of deleting an integration release
46 4 Erica Snider
*** If an objection is raised to a planned deletion, the release in question will not be deleted pending a further discussion and decision at a subsequent LArSoft Coordination Meeting.
47 4 Erica Snider
48 4 Erica Snider
* Retention policy for nightly releases [implemented by convention without approval]
49 4 Erica Snider
** Nightly releases will be retained for no more than one week. 
50 4 Erica Snider
** Proposed changes to this period should be discussed at a LArSoft Stakeholders or Steering Committee meeting.