[INTPAK-18] Allow manually setting package version Created: 01/Nov/17 Updated: 15/Jan/18 Resolved: 15/Jan/18 |
|
| Status: | Closed |
| Project: | integration-packaging |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Low |
| Reporter: | Daniel Farrell | Assignee: | Daniel Farrell |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
In the packaging scripts, pkg_version (x.x.x-pkg_version) is hardcoded to 1 for release packages. If we need to re-release the same ODL version with a packaging change, we need to be able to bump that version. The logic that extracts version info from URLs also assumes the tarball is hosted in one of a few locations. By enabling us to skip that logic and provide the version directly, we would be able to package tarballs hosted anywhere. Maybe it should be some sort of generic "version override", where the user can pass a version instead of the scripts trying to do the extract_version logic to find the version from the URL. This would also be helpful if we need to package a tarball that's at some unexpected URL, like a contributor has uploaded it to Google Drive or something in the build system changes URLs and we haven't adjusted the packaging logic to handle the change yet. We don't have to make this a very user-friendly param, like we had with each individual version component param. Can just be something like --version-override=" {major: 6, minor: 2, patch:0, pkg: 1}" for Carbon SR2 for example. |
| Comments |
| Comment by Daniel Farrell [ 15/Jan/18 ] |
|
Talking with the original reporter, I think this is not actually needed. Can reopen if it comes up again. |