Uploaded image for project: 'Request For Comments'
  1. Request For Comments
  2. RFC-99

Stack tagging / versioning convention

    Details

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

      Description

      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}
      

        Attachments

          Issue Links

            Activity

            Hide
            frossie 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 Frossie Economou added a comment - I am withdrawing this RFC, a new one on this topic will be submitted after work in Spring 2017
            Hide
            tjenness 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
            tjenness 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
            zivezic Zeljko Ivezic added a comment -

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

            Show
            zivezic Zeljko Ivezic added a comment - Don's opinions seem perfectly correlated with mine. Abstained.
            Hide
            petravick 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
            petravick 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
            swinbank 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
            swinbank 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
            swinbank 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
            swinbank 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.

              People

              • Assignee:
                frossie Frossie Economou
                Reporter:
                frossie Frossie Economou
                Watchers:
                Donald Petravick, Frossie Economou, John Swinbank, Kian-Tat Lim, Tim Jenness, Zeljko Ivezic
              • Votes:
                0 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Planned End:

                  Summary Panel