# Stack tagging / versioning convention

XMLWordPrintable

## Details

• Type: RFC
• Status: Withdrawn
• Resolution: Done
• Component/s:
• Labels:
None
• Location:
SQuaRE hipchat room and/or this ticket

# Version RFC

## Scope

The following naming scheme is applied to Science Pipeline Stack repos, currently defined as:

• any repo explicitly pulled in by the lsst_distrib TLP
• any repo belonging to LSST:DM Auxiliaries on Github
• any repo belonging to LSST:DM Externals on Github

Other TLPs for DM teams are welcome to use these conventions (or in the case of the official releases, may have these conventions applied) by appending their TLP to the suggested tag. Eg. r.Summer2015.qserv or r.Winter2015.firefly. Non-DM teams are welcome to adopt these conventions (eg r.Winter2015.sims). Teams that adopt these conventions can request that SQuaRE apply these tags if they so wish.

## Reserved namespaces for administrative releases: r

Permanent (won't be deleted) git tags for end-of-cycle administrative releases reserve the r namespace for the cycle name. Eg.

• r.Summer2015
• r.Winter2016

Note: PMCS/LDM-240 will be changed to refer to these release names in lieu of the current 5.0 6.0 etc numeric nonmenclature) for consistency and traceability.

## Reserved "namespaces" for engineering releases: w/m/d

These namespaces will refer to:

1. Impermanent (see below) git tags
2. Impermanent (see below) distributions

Examples:

• Weeklies: w.YYYY.WW eg w.2015.37 is 37th week of 2015
• Monthlies: m.YYYY.MM
• Dailies: d.YYYY.MM.DD

These will be published on the EUPS distrib server as w_2015_37 etc.

These will NOT be EUPS product versions (the latest version of EUPS with Mario's fix to ignore them will be installed on lsst-dev). They will be pruned to reduce noise on a timescale consistent with their granularity - eg no more than six months of monthlies.

## Numeric (Public) Releases: v.N.n and N.n

Right now there is a numeric release scheme; currently this a non-semantic representation mapping to cycle and number of release in cycle. For example: 11.0 is the first release of W16, 11.1 is the second release in that semester, etc.

Without getting into the merits of numeric release versions or their convention, there are two git tags for numeric releases, bareword and prepended with a v. For releases aimed at external (non-DM) consumption, both will be applied: v.11.0 and v11.0.

NOTE: In this RFC, the bare numeric tag (11.0) is the only one that is reflected as an EUPS product version. The rest are "invisible" to EUPS (though will be used for eups distrb install publication, as in weeklies). In the future, internal packages may go to different bareword numbering systems (e.g. semver or YYYY_MM).

## Candidate releases for Official Releases: *_rcN

Candidate release conventions are tied into the SQuaRE's release preparation process and so may change arbitrarily, as they are evanescent and largly for internal consumption. They are tagged on a naming scheme

 {bare numeric version}_rc{candidate number} 

• do not apply these tags without direction from SQuaRE.

## Other schemes

Groups are free to make tags as useful to them, provided they don't stomp on the conventions above. Each product could adopt its own monotonically-increasing numeric bareword tagging scheme, but the

  [dmrvw]. 

space is reserved for the above - including

 [dmrvw].*.{product} 

## Activity

Hide
John Swinbank added a comment - - edited

Some of the jargon tripped me up while reading through this. For the benefit of anybody else having the same problem, here are some notes. Apologies to those for whom this is obvious (particularly if that turns out to be everybody except me).

• TLP: Top Level Product. Something you are likely to eups distrib install to pull in a workable collection of software. E.g. lsst_distrib or lsst_apps, but not pex_policy or skymap.
• LSST:DM Auxiliaries: a GitHub team which owns repositories which are necessary for the stack release process but which are not direct dependencies of the code, e.g. lsstsw, lsstDoxygen.
• LSST:DM Externals: a GitHub team which owns all the repositories containing third-party packages required by the stack, e.g. boost, eigen.
• the latest version of EUPS with Mario's fix: This refers to an outstanding PR against eups. It modifies the process by which eups generates version numbers for products so that it now uses strictly numeric versions rather than trying to incorporate alphanumeric tags such as w_YYYY_DD. I assume that PR will ultimately make its way into an eups release, but it hasn't yet.
Show
John Swinbank added a comment - - edited Some of the jargon tripped me up while reading through this. For the benefit of anybody else having the same problem, here are some notes. Apologies to those for whom this is obvious (particularly if that turns out to be everybody except me). TLP : Top Level Product. Something you are likely to eups distrib install to pull in a workable collection of software. E.g. lsst_distrib or lsst_apps , but not pex_policy or skymap . LSST:DM Auxiliaries : a GitHub team which owns repositories which are necessary for the stack release process but which are not direct dependencies of the code, e.g. lsstsw , lsstDoxygen . LSST:DM Externals : a GitHub team which owns all the repositories containing third-party packages required by the stack, e.g. boost , eigen . the latest version of EUPS with Mario's fix : This refers to an outstanding PR against eups . It modifies the process by which eups generates version numbers for products so that it now uses strictly numeric versions rather than trying to incorporate alphanumeric tags such as w_YYYY_DD . I assume that PR will ultimately make its way into an eups release, but it hasn't yet.
Hide
John Swinbank added a comment -

My chief comment on this proposal is that it seems like an awful lot of different types of release. Can we break down the reasons why they're all necessary? In particular:

• I think the split into "numeric (public) releases" and "administrative releases" is new. Is it necessary?
• What sort of testing or QA do we expect to perform on daily, weekly, monthly releases? Will weeklies undergo more testing than dailies? If the answer is no, then what's the distinction between a weekly and a daily that happened to be released on (say) a Monday? If the answer is yes, then... what?
• Why do we need to have both bare and v.-prefixed numeric releases?

Somewhat related to the above, can we outline the requirements for each type of release? For example, when are we supposed to provide release notes or performance metric values?

Exposing my naivety: I have installed lsst_apps tagged w_2015_35 using eups distrib install. The installed version is 10.1-3-gc3ee848+8 – it's not versioned as some variation on w_2015_35. That's despite Mario's patch not yet being in a released version of eups. Given that, I'm not totally sure that I really understand the comments about what will be exposed as product versions above.

What's the rationale for _ vs . in tag names? Is there a reason we can't be consistent between eups and git?

Show
John Swinbank added a comment - My chief comment on this proposal is that it seems like an awful lot of different types of release. Can we break down the reasons why they're all necessary? In particular: I think the split into "numeric (public) releases" and "administrative releases" is new. Is it necessary? What sort of testing or QA do we expect to perform on daily, weekly, monthly releases? Will weeklies undergo more testing than dailies? If the answer is no, then what's the distinction between a weekly and a daily that happened to be released on (say) a Monday? If the answer is yes, then... what? Why do we need to have both bare and v. -prefixed numeric releases? Somewhat related to the above, can we outline the requirements for each type of release? For example, when are we supposed to provide release notes or performance metric values? Exposing my naivety: I have installed lsst_apps tagged w_2015_35 using eups distrib install . The installed version is 10.1-3-gc3ee848+8 – it's not versioned as some variation on w_2015_35 . That's despite Mario's patch not yet being in a released version of eups. Given that, I'm not totally sure that I really understand the comments about what will be exposed as product versions above. What's the rationale for _ vs . in tag names? Is there a reason we can't be consistent between eups and git?
Hide
Donald Petravick added a comment -

KT as asked for a TCT vote on this matter. I ABSTAIN as see no objection in this matter, but do not have information judge at more than a trivial level of detail.

Show
Donald Petravick added a comment - KT as asked for a TCT vote on this matter. I ABSTAIN as see no objection in this matter, but do not have information judge at more than a trivial level of detail.
Hide
Zeljko Ivezic added a comment -

Don's opinions seem perfectly correlated with mine. Abstained.

Show
Zeljko Ivezic added a comment - Don's opinions seem perfectly correlated with mine. Abstained.
Hide
Tim Jenness added a comment - - edited

It seems like this RFC has been flagged to the TCT (but is still in proposed state). Frossie Economou are you still wanting to adopt this RFC or has it been superseded?

For the record the EUPS PR was accepted in October 2015.

Show
Tim Jenness added a comment - - edited It seems like this RFC has been flagged to the TCT (but is still in proposed state). Frossie Economou are you still wanting to adopt this RFC or has it been superseded? For the record the EUPS PR was accepted in October 2015.
Hide
Frossie Economou added a comment -

I am withdrawing this RFC, a new one on this topic will be submitted after work in Spring 2017

Show
Frossie Economou added a comment - I am withdrawing this RFC, a new one on this topic will be submitted after work in Spring 2017

## People

• Assignee:
Frossie Economou
Reporter:
Frossie Economou
Watchers:
Donald Petravick, Frossie Economou, John Swinbank, Kian-Tat Lim, Tim Jenness, Zeljko Ivezic