Project

General

Profile

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