Add releases_future_release_uri config
#54
Conversation
…'t have the same link as already existing releases. (Git tags vs. a current development branch, for example)
|
I have added the new option to the default config in 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 |
See also: - bitprophet/releases#54 (original PR by @scolby33) - bitprophet/releases#76 (rebased branch of above PR used in this commit) - Feature request: bitprophet/releases#65
Remove releases in favor of a more sphinx-issues and basic reST structuring. https://github.com/bitprophet/releases was inflexible in cases where we used v<versionnumber> (v1.2.2) and wanted to link back to master. Issue / PR: - bitprophet/releases#54 - bitprophet/releases#76 Other issues is how the behavior did more than styling and issue linking, sometimes patches only intended for minor releases were also added to minor releases. Regardless of what it intended to do, it wasn't compatible with how releases were cut. It does more than the projects I added to needed. Instead of using reST sections, it used list items to represent versions. Which then go on to build html that a section would anyway. This feels out of place when separating versions. Custom roles used in releases were way too much investment for a changelog. It'd be worth seeing if the same job could be done by iterating over node test and linking to issues like GitHub does. e.g #484
bitprophet
force-pushed
the
main
branch
8 times, most recently
from
cda450e to
80e1d49
Compare
bitprophet
force-pushed
the
main
branch
4 times, most recently
from
8d2fe0c to
b18cd60
Compare
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/vmasteris bad.Scenario 2:
releases_release_urican be the defaultmasterbut are ondevelop, so the default link tohttps://github.com/you/project/tree/masteris bad.This pull request solves both of these problems by adding the
releases_future_release_uriconfig, 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...