Package versioning¶

Currently packages are built with a version constructed from timestamp of the most recent git commit of the tool and/or its dependencies with the arvados source tree. This has the advantage that package versions reflect the most recent actual change and are not constantly rebuilt. However, this does not provide for a way to identify the set of packages associated with a specific git commit.

Proposal: build a set of metapackages that are versioned against the entire Arvados source tree and point to the "head" package version of each component. For example (timestamps are truncated only to make them easier to read in this example):

meta-python-arvados-cwl-runner_1.0.20161018 → python-arvados-cwl-runner_1.0.20160901

Every time Jenkins runs the package build script, it also creates meta-xxxx packages versioned based on the git head being built.

Stable release versioning adds another layer of metapackages defined based on "external" versions:

release-python-arvados-cwl-runner_16.10 → meta-python-arvados-cwl-runner_1.0.20161018

2016-10-26 nico --- Comments on the proposal: filling the blanks with metapackages that point to a version will make a HUGE amount of metapakages that will make things worse. It will be the "correct" information but the repo will be filled by thousands of meta packages (almost all of them pointing to very few versions of actual packages)

Testing/stable repositories¶

We package building should publish only to a testing repo for distribution to internal clusters (4xphq, c97qk, 9tee4). Packages should be manually graduated to a stable repo when ready to be distributed to customer-facing clusters.