Open scolby33 opened 8 years ago
I have added the new option to the default config in tests/_util.py
.
I spent a while trying to find a good way to integrate this change in your tests, but couldn't seem to make it work without resorting to major changes of the test suite. Perhaps you have some pointers as to how I could implement the tests?
It is getting super late (early...) for me, so I'll pick this back up tomorrow.
@scolby33 @bitprophet See also: #65
See "Next release" in https://libtmux.git-pull.com/en/latest/history.html. It links to vmaster instead of master.
@scolby33 I made a rebase of this at #76. I'm not fully sure if you'd get credit on GH if I made the PR or not. But you are free to rebase on your own or use my rebase on this PR.
@bitprophet This would handle #65 for me. Specifically, we have an issue where we break the normal URL convention sometimes and may want something like this:
releases_release_uri = "https://github.com/tmux-python/libtmux/tree/v%s"
releases_future_release_uri = "https://github.com/tmux-python/libtmux/tree/%s"
The reason why is I prefix version releases with v
, e.g. v1.0.0
, but unreleased trees are master
. So we don't want to use the same template.
Scenario 1:
releases_release_uri = 'https://github.com/you/project/releases/tag/v%s'
master
! So the automatic link tohttps://github.com/you/project/releases/tag/vmaster
is bad.Scenario 2:
releases_release_uri
can be the defaultmaster
but are ondevelop
, so the default link tohttps://github.com/you/project/tree/master
is bad.This pull request solves both of these problems by adding the
releases_future_release_uri
config, allowing a custom URI to be set for "faux-releases" separately from normal releases.I have tested this with my own project and have attempted to run your test suite, but I am not 100% sure I did that correctly, so the running of tests on your end would be appreciated.
EDIT: I see you have Travis integration. Let me write some tests for this feature...