LArSoft release naming policy » History » Version 8
Erica Snider, 04/04/2017 02:59 PM
1 | 3 | Erica Snider | h1. LArSoft release naming and retention policy |
---|---|---|---|
2 | 1 | Erica Snider | |
3 | 4 | Erica Snider | h2. Release naming policies |
4 | 4 | Erica Snider | |
5 | 8 | Erica Snider | * All LArSoft release versions and core LArSoft products will use the following numbering convention: vMM_mm_pp |
6 | 1 | Erica Snider | ** MM = major number, mm = minor number, pp = patch number |
7 | 1 | Erica Snider | ** Releases that require a fork in order to fix a problem will have a suffix added after the patch number |
8 | 7 | Lynn Garren | *** *A fork is required if and only if the release to be patched is not the latest release available* |
9 | 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,... |
10 | 1 | Erica Snider | * Version numbers will be incremented according to the following policy: |
11 | 1 | Erica Snider | ** The patch number will increment for routine weekly integration releases or bug fixes |
12 | 1 | Erica Snider | ** The minor number will increment when new features or changes in functionality are introduced |
13 | 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. |
14 | 1 | Erica Snider | *** Interface changes that can be considered |
15 | 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: |
16 | 1 | Erica Snider | *** Changes to data products that are not backwards compatible |
17 | 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) |
18 | 1 | Erica Snider | *** Changes to any of the major external dependencies (e.g., root, gcc) |
19 | 1 | Erica Snider | |
20 | 6 | Katherine Lato | Before new major releases of software are put into production each experiment signs off as accepting the code. Tests are encouraged using the continuous integration infrastructure. Minor releases of software are released weekly, with each experiment providing information of what code from the experiment specific branches they would like in the release. |
21 | 4 | Erica Snider | |
22 | 4 | Erica Snider | h2. Release retention policies |
23 | 4 | Erica Snider | |
24 | 4 | Erica Snider | * Releases are categorized into three classes for the purposes of retention policy |
25 | 4 | Erica Snider | ** Production |
26 | 4 | Erica Snider | ** Integration (sometimes referred to as "weekly") |
27 | 4 | Erica Snider | ** Nightly |
28 | 4 | Erica Snider | |
29 | 4 | Erica Snider | |
30 | 4 | Erica Snider | * Retention policy for production releases |
31 | 4 | Erica Snider | ** Production releases will announced as such to the LArSoft community and identified on the [[LArSoft release list]] page. |
32 | 4 | Erica Snider | *** The determination of what releases qualify as "production" will be made by the experiments. |
33 | 4 | Erica Snider | *** The affirmation of a single experiment is sufficient to declare a release as "production". |
34 | 4 | Erica Snider | ** Production releases will be retained indefinitely. |
35 | 4 | Erica Snider | *** Removal of production releases will be coordinated with the experiment(s) that requested the production status. |
36 | 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. |
37 | 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. |
38 | 4 | Erica Snider | |
39 | 4 | Erica Snider | * Retention policy for integration releases |
40 | 4 | Erica Snider | ** Unless otherwise specified, a tagged release will be considered as an "integration" release. |
41 | 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. |
42 | 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. |
43 | 4 | Erica Snider | ** Integration releases will be deleted as space is needed |
44 | 4 | Erica Snider | *** An announcement will be made to the "larsoft" email list at least one week in advance of deleting an integration release |
45 | 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. |
46 | 4 | Erica Snider | |
47 | 4 | Erica Snider | * Retention policy for nightly releases [implemented by convention without approval] |
48 | 1 | Erica Snider | ** Nightly releases will be retained for no more than one week. |
49 | 1 | Erica Snider | ** Proposed changes to this period should be discussed at a LArSoft Stakeholders or Steering Committee meeting. |
50 | 6 | Katherine Lato | |
51 | 6 | Katherine Lato | Policies were established and approved at the May 6, 2014 LArSoft Librarian's Meeting: https://indico.fnal.gov/categoryDisplay.py?categId=405 |