At any given moment, we could have up to four branches open:
development branch for current stable patch releases. (8.2.x)
development branch for an upcoming minor release in beta/rc phase (8.3.x)
development branch for next minor release (8.4.x)
development branch for the next major release (9.x-dev)
Issues like #2268449: Run contrib module branch tests against both dev and latest stable core branches → , #2651208: More-flexible, while reasonable, configured tests → and 🌱 [policy, then infra] Bulk update core issues for relevant minor versions Fixed might be simplified if we were able to refer to them with labels, rather than the specific branch names.
If issues were tied to labels, they would be easier to move by reassigning the version associated with a label vs re-assigning the issues to new versions.
Use branch labels in the UI in addition to the branch versions they represent:, rather than only actual branch names, for example:
8.2.x-supported
8.3.x-prerelease
8.4.x-development
9.x-maj-development
An additional label that would be useful for drupalci would be 'stable' (8.2.5)
Some suggested semantic labels could be:
stable - This is the current stable release Tag: (8.2.5 currently)
supported - This is the current patch level/bugfix branch. (8.2.x, currently)
prerelease - This is the label for when a development branch reaches the beta->rc cycle (8.3.x, soon)
development - This is where new, backwards compatible feature development is added (8.4.x, soon)
major-development - This is where new, non backward compatible feature development is added.
Decide on label UX, and semantic label names (8.2.x-supported vs supported (8.2.x) etc)
Change drupalci and project to use them.
Needs an interface for project maintainers to assign them to versions.
Update existing issues that are tied to stable versions to something. ( https://www.drupal.org/node/2691889 → )
Postponed: needs info
11.0 🔥
documentation
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
It has been rather quiet here. Is this still desired? And, is it possible in the GitLab UI to name branches in this way?
Most of what I was hoping to improve here is covered by 🌱 [Policy] Branch Naming: Use an 11.x branch for HEAD, then use 'main' when d.o can support it Fixed .
Marking as outdated.