Move master version ahead of the last tag #2792
Comments
|
Do people really want to support building with different wlroots versions? Looks like it would be some pretty annoying |
|
For example, A project |
|
Right. Some projects use version numbers like |
|
Yeah, let's not break version number continuity with hacks like that. The cleanest method is probably just bumping the minor immediately after a tag, so master basically always represents an alpha/beta of a future release. It's the same amount of work as bumping before a release, although harder to remember to do. If we want to do a major release then two bumps will end up occurring between releases, but it shouldn't have any consequence. Patch releases when made on a maintenance branch from a release tag should be unaffected. The "snapshot" version approach, just like the hack version number, is more of a chore as it requires first setting a real version number, tagging the release, then undoing the real version number again. |
That sounds like a good idea. |
We now bump the version number right after releases, so that a Git snapshot is not mistaken for a previous version. References: #2792
|
Done in 1c10079. I've also updated the instructions on the wiki: https://github.com/swaywm/wlroots/wiki/Core-contributor-guide#releasing-a-new-version |
Consumers may want to support both latest release and master snapshot. To do so they can check
WLR_VERSION_*but because wlroots only bumps minor version just before a tag is created it's not usable. So, some consumers choose to not support wlroots master until after the changes end up in a release that may end up being less stable due to not being tested in advance.The text was updated successfully, but these errors were encountered: