# What is the current versioning scheme? **URL:** \ **Category:** Data Management\ **Tags:** square\ **Created:** [December 24, 2015, 9:39am UTC](https://www.rubin.community/t/what-is-the-current-versioning-scheme/459 "2015-12-24T09:39:45Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![mjuric](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/mjuric/32/31_2.png) [@mjuric](https://www.rubin.community/u/mjuric)\ **Post date:** [December 24, 2015, 9:39am UTC](https://www.rubin.community/t/what-is-the-current-versioning-scheme/459/1 "2015-12-24T09:39:45Z")
Hi everyone! I was going to do some work on the conda binary packaging, when I noticed that the versioning scheme of stack products has changed. E.g. in [b1833](https://github.com/lsst/versiondb/blob/master/manifests/b1833.txt) there are products with versions such as `2015_10.0-...`. What’s the algorithm for assignment of new version numbers? I tried looking here and on Confluence but had no luck (I found [https://dev.lsstcorp.org/trac/wiki/OnVersionNumbers](https://dev.lsstcorp.org/trac/wiki/OnVersionNumbers), but that seems out of date). I ask because I need to make sure `conda` package versions (which I’ve so far derived from EUPS versions) are always ascending so updates continue to work reliably. E.g., it’d be bad if I put out a `2015.10.0` version (these are the monthlies?), followed by a `12.0` (the official release). ---
**Author:** ![ktl](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/ktl/32/1373_2.png) [@ktl](https://www.rubin.community/u/ktl)\ **Post date:** [December 24, 2015, 1:53pm UTC](https://www.rubin.community/t/what-is-the-current-versioning-scheme/459/2 "2015-12-24T13:53:50Z")
Versions of individual eups products are currently in a bit of flux due to overlapping builds for Science Pipelines and Qserv. See thread at [https://listserv.slac.stanford.edu/cgi-bin/wa?A1=ind1512&L=QSERV-L#1](https://listserv.slac.stanford.edu/cgi-bin/wa?A1=ind1512&L=QSERV-L#1). I think that tags are currently the most reliable way of accessing consistent versions. ---
**Author:** ![mjuric](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/mjuric/32/31_2.png) [@mjuric](https://www.rubin.community/u/mjuric)\ **Post date:** [December 24, 2015, 8:56pm UTC](https://www.rubin.community/t/what-is-the-current-versioning-scheme/459/3 "2015-12-24T20:56:24Z")
Thanks K-T! Reading @frossie’s [response](https://listserv.slac.stanford.edu/cgi-bin/wa?A2=ind1512&L=QSERV-L&F=&S=&P=8758) I couldn’t quite figure out if the current state (having versions such as `2015_11`, etc.) is a bug or a feature? I see a reference to a future meeting – has anything been decided there? I’m mostly interested in whether we’ll continue to have ordering defined on the versions, and what’s the comparison scheme (e.g., prior versions were guaranteed to be comparable with the [VersionCompare class](https://github.com/RobertLuptonTheGood/eups/blob/master/python/eups/VersionCompare.py)). That will make it possible for me to correctly decode & reformat the versions, to be compatible with `conda`'s [version ordering](https://github.com/conda/conda/blob/master/conda/resolve.py#L30) scheme. ---
**Author:** ![frossie](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/frossie/32/9_2.png) [@frossie](https://www.rubin.community/u/frossie)\ **Post date:** [December 28, 2015, 10:52pm UTC](https://www.rubin.community/t/what-is-the-current-versioning-scheme/459/4 "2015-12-28T22:52:53Z")
@mjuric - see RFC-99, which is what we’re trying to go to. The \_11 etc versions come from the Qserv convention, now that I am doing their releases I’m trying to unify the process (and mostly succeeding). We do need to talk about what EUPS does with those things when you have some time.