The "Early access" page is somewhat inconsistent
TLDR: The current release descriptions are confusing and could benefit from an overhaul focusing on making it more consistent, especially in regards to what "stable" means for each release.
Long version
I think the current branching strategy leads to a bit of confusion. I don't know if that's because I'm misunderstanding the description of each branch or because there's an underlying issue, so I'll try to describe how I interpret the workflow and how I think communication about it could be improved. Please let me know if any of my points are due to a misunderstanding on my end
Below is my understanding of the workflow and the docs. The "dev changes" columns describes, what the criteria there is for a change to be included. Upstream is which version of upstream is included in that build.
Dev changes | Upstream | |
---|---|---|
hbs |
Stable | Target version |
hbt |
Next release | Target version |
hbk |
Feature complete | Latest Stable |
hbl |
Latest | Latest Stable |
hbd |
Latest + WIP | Master |
It was difficult for me to come up with precise definitions, especially for the upstream column. As an example, both
At the same time there's the references to semantic versioning which is not reflecting the actual builds (
The combination of these things makes it difficult to predict, what I'll end up with for each of the branches and what the purpose of each of them are.
As far as I can understand, the biggest issue is, that each branch is trying to version two sources in a single piece of information.
Proposal
A solution could be to assign separate animals to OpenWrt and dev changes, then define the branch by the scariest animal. It might be a good idea to assign two animals to OpenWrt - one based on the upstream tag and one for how well it runs with TOS.
Examples
Master branch of OpenWrt and master dev changes will have zoo version:
OpenWrt (
Current stable OpenWrt and latest stable features:
OpenWrt (
I understand it requires resources to implement these kind of things in a deployment pipeline and keep the docs up to date. However from an end-users perspective it's currently hard to understand what is meant by "stable" in the docs and what software will actually end up on my device based on my choice of branch.