Package versioning » History » Version 2
Peter Amstutz, 10/25/2016 01:48 PM
| 1 | 1 | Peter Amstutz | h1. Package versioning |
|---|---|---|---|
| 2 | |||
| 3 | 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. |
||
| 4 | |||
| 5 | 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): |
||
| 6 | |||
| 7 | meta-python-arvados-cwl-runner_1.0.20161018 → python-arvados-cwl-runner_1.0.20160901 |
||
| 8 | |||
| 9 | Every time Jenkins runs the package build script, it also creates meta-xxxx packages versioned based on the git head being built. |
||
| 10 | |||
| 11 | Stable release versioning adds another layer of metapackages defined based on "external" versions: |
||
| 12 | |||
| 13 | release-python-arvados-cwl-runner_16.10 → meta-python-arvados-cwl-runner_1.0.20161018 |
||
| 14 | 2 | Peter Amstutz | |
| 15 | h2. Testing/stable repositories |
||
| 16 | |||
| 17 | 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. |