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 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, 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).
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. I think that tags are currently the most reliable way of accessing consistent versions.
Reading @frossie’s response 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). That will make it possible for me to correctly decode & reformat the versions, to be compatible with conda's version ordering scheme.
@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.