Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement reasonable "release" versioning #21

Open
mjuric opened this issue Jul 10, 2015 · 1 comment
Open

Implement reasonable "release" versioning #21

mjuric opened this issue Jul 10, 2015 · 1 comment

Comments

@mjuric
Copy link
Owner

mjuric commented Jul 10, 2015

Current LSST release versioning is implemented using EUPS tags. For example, to obtain the "10.1" release of the software, a user is advised to do:

eups distrib install -t v10_1 lsst_distrib

or

eups distrib install -t v10_1 afw

This is very useful, as it makes it easy to install well QA-ed releases of the software suite.

Conda has no concept of tags, so a different mechanism is needed to provide similar functionality. There are two options I can think of:

  • channels: for each EUPS tag, we create a new channel. The analog of above would then be:

    conda install -c http://eupsforge.net/conda/releases/0.10.1 lsst-distrib
    conda install -c http://eupsforge.net/conda/releases/0.10.1 lsst-afw
    
  • metapackages: for each EUPS tag, we create a -release metapackage on the few top-level products:

    conda install lsst-distrib-release=0.10.1
    

The pros of the former include almost perfect equivalence with EUPS tag functionality, and a mental model of a release branch (i.e., the releases/0.10.1 channel could be updated with further point releases). The major con is the requirement to specify a full URL as -c argument.

The pros of the latter include similarity to current conda practices and simplicity. The cons include having to remember to append -release to the package name, and either having to produce -release metapackages for all packages, (to enable something like conda install lsst-afw-release=0.10.1), or doing it just for the top-level packages and not providing that functionality.

@mjuric
Copy link
Owner Author

mjuric commented Jul 10, 2015

Q: Why not just use the version of (say) lsst_distrib?
A.1: Because there's a new version out with every buildbot rebuild -- it tracks the master. I think LSST's internal versioning scheme would have to change to support something like this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant