[policy, no patch] Branch labels for core

Labels++

@catch clarified to me that the proposal was only about what we display to people, and that we would still have 8.0.x / 8.1.x / 8.2.x in git (or at least we don't have to change the git branching model in order to do this).

We also talked about the fact that #2631820: [policy, then infra] Bulk update core issues for relevant minor versions does have advantages because it communicates more to contributors on issues, and it accounts for the beta and RC phases in a way that branch naming alone couldn't (related the point about minor becomes dev becomes minor in the summary). With explicit numbers, we can capture that a certain issue is backported to 8.1.x despite being disruptive because it was important to add during the beta, or even that an issue is important enough to backport to 8.0.x for an unscheduled hotfix after the final scheduled patch release.

Use branch labels in the UI, rather than the actual branch names

Thumbs down.

Change to 'in addition to' and it's thumbs up.

Also add 8.x-RELEASE for the latest official stable release so I can specify my contrib to test only against the release version.

There's also a 9.x-DEV already. :-)

Yes, both the version and the label should be present in the version selector. There shouldn't be a need for a documentation decoder ring to figure out what the values mean. Maybe something like:

• 8.x stable branch for patch releases, currently 8.0.x
• 8.x development branch for next minor release, currently 8.1.x
• 8.x development branch for future minor releases, currently 8.2.x

Shortening all the way to patch/minor/dev is something I can barely wrap my head around as someone who hasn't been too involved in roadmap discussions and hasn't kept semver definitions at the top of my mind. I expect my copyediting is a bit too long, especially for issue listings.

What UI are you actually talking about here? I'm confused...

Ah. OK, my 2 cents:

To me, 8.x-PATCH, 8.x-MINOR, and 8.x-RELEASE are not clear, without an explanation. Whereas 8.1.x-dev is clear, without an explanation.

So, there are several groups of people who might be confused by either the present labels or different labels.

a) Experienced core developer (such as myself). I notice a bug or want to propose a feature. I generically know it needs to be filed (currently) against whatever the largest 8.x number is, or against 9.0.x, depending on whether it's 8.x or 9.x material. It is easy enough for me to figure out 8.x-DEV or 8.x-2.x. I don't think I benefit much from the new labels, but -DEV, -NEXT, -STABLE I can at least figure out better than -PATCH, -MINOR, -RELEASE (I really had no idea what those meant). -DEV, -TESTING, -STABLE... I guess those are OK too. But either one kind of has me scratching my head. And one more thing... like xjm/#7, I also like the clarity of having an issue be targeted to a clear release, and communicating clearly when it needs to be moved.

b) Core developer making a patch for an issue. It's filed against 8.x-DEV. So, I go to the command line, and do git checkout... hm... git checkout what exactly? So this seems like it's very confusing for especially a new developer, to figure out what branch (which is numbered) to check out to make a patch for a given issue. For this user group, I think having the actual numbers in the UI is much much better and clearer.

c) Drupal site builder who finds a bug. The site is running Drupal 8.2.3. What do they file the issue against? Well, probably they'll file it against 8.2.3 (that is basically what people often/always do, file it against the version they're actually running, at least I see that a lot). But at least if 8.2.x is in the list, there's a chance they may see that and file it there. I doubt they would immediately understand whether -STABLE, -NEXT, -DEV, -TESTING, -PATCH, -MINOR, or -RELEASE means at all. I think these would confuse this user group.

I see from a few previous comments that the idea might be to *add* labels in addition to the actual branch numbers, rather than replace them... but I think I'm also kind of against that. I don't think we should have two choices in the UI that are really the same thing, because... which one should I choose? It seems very confusing. Plus, we already have around 40 choices in the UI for 8.x issues... not convinced we need that number to be 43.

So... I'm not seeing what the benefit is of this idea... all I see is that it seems confusing if we replace the actual branches with different labels (besides the coding difficulties), and confusing plus more overwhelming than it already is if we add new options for labels to choose that are fluid, in addition to the ones we already have that point to definite branches.

The current policy of putting 8.anything issues into 8.0 is not really working, as far as I can tell. The patches need to be applied to 8.2 first and then backported (if necessary) to 8.1, then 8.0. I think they all need to be filed against 8.2 and have backport tags, just as we would do if something was applicable to 8.x and 7.x.

Anyway. I like the idea of making 1 entry per branch and making them look like "8.2.x - development" etc. That adds information rather than confusing things.

The current policy of putting 8.anything issues into 8.0 is not really working, as far as I can tell. The patches need to be applied to 8.2 first and then backported (if necessary) to 8.1, then 8.0. I think they all need to be filed against 8.2 and have backport tags, just as we would do if something was applicable to 8.x and 7.x.

Well, actually, the policy has worked for like... 95% or more of issues committed to 8.0.x since 8.0.0 (the vast majority of issues cherry-picked cleanly). Also, the policy is not that "8.anything issues [go into] 8.0"; it's that only issues eligible for 8.0.x get filed against 8.0.x. I agree that it's not perfect--it was an interim solution when 8.0.0 was released and we needed to deal with 8.1.x being open--but it's also mostly worked until now. The branch selection has actually been a very important part of communicating semver requirements to people.

I don't think the solution is just to add more backport tags; they are not explicit or visible enough and don't actually reflect our process for D8. That's where #66484: Allow issues to be filed against multiple versions/branches. comes in, and to some extent #2623118: [policy, no patch] Update patch backporting workflow to be compatible with semantic versioning. Also, we are making progress on getting away from the entire idea of backport tags in #2462101: [policy, no patch] Update backport policy to account for 8.x minor versions and 7.x divergence.

I totally agree that "make the issue 8.0 if it should go into all branches" worked fine when all we had was 8.0 and 8.1, and everyone was so tired out after getting 8.0 out the door, not much was happening in Core.

But now that we also have 8.2, and now that things are starting to diverge and the patches don't apply to all 3 branches as often, I don't think it's working as well.

Anyway. Sorry, noise.

Maybe we should discuss this on a separate issue, but ... My suggestion would be that issues are always filed against the latest branch that they apply to (so they'd all go against 8.2 at the moment). It seems like when we have an RTBC patch, the committers are the ones who have to decide which branch(es) to commit it to, right? But pretty much all patches have to go into 8.2 before they get applied to 8.1/8.0/7, so they have to apply to 8.2 and be tested against 8.2 as a priority. Then after making the commit, if the committer decides it belongs in 8.1 or 8.0 or 7, they can either apply the patch directly or cherry-pick, or if the patch doesn't apply due to divergence, they can then put the issue in the other branch and mark it Patch (to be ported).

But if we file/patch/test vs. 8.1 or 8.0 to begin with, then the patch sometimes doesn't apply to 8.2 when it comes time to commit, and in the end the committer *still* has to make the decision as to whether it belongs in the older branches.

The problem I see with #21 is that it places the intellectual burden entirely on the committer and makes it appear that only committers can decide. And then committers have to do the emotional labor of telling people why their patch is or isn't backported as well. Whereas by making it a first-class part of issue metadata (either with the current practice or this proposal), we make it clear that it is everyone's responsibility, and committers are just signing off (or occasionally not). Backport tags cause similar problems.

The easiest, lowest risk, lowest effort for thing for a committer to do is to commit everything to (at the moment) 8.2.x and just mark it fixed. But that's not what is best for Drupal, because sites also need bugfixes in patch releases.

I agree that it's confusing, and sometimes patches might be created that don't apply to 8.2.x. But I think it's the least confusing of everything we've tried to date with the current feature set of project_issue.module. To make it even less confusing, we should improve the tool. This proposal is one way to do that. #66484: Allow issues to be filed against multiple versions/branches., #2631820: [policy, then infra] Bulk update core issues for relevant minor versions, #2691889: Add option to remove tagged releases from the version selector, #2691895: Remove unsupported branches/releases from the version selector are others.

I'd prefer not to change the current practice at this time. I'd rather tough it out for one more week until 8.0.x is EOL, and then we are back to essentially where we were at 8.0.0 except that it's even easier because issues are mostly in the right branches and every one of them with a helpful system message linking the relevant docs. Meanwhile, we can continue working on improving the usability of the tools through these different proposals. Hopefully the tools will catch up by the time either 8.1.x and 8.2.x have diverged to the point that backport ping-pong is again an irritant or 8.3.x is branched. And if they haven't, then we could revisit @jhodgdon's suggestions or other alternatives.

OK. For issues I deal with (documentation mostly), then I'll be putting them back into 8.0 (soon: 8.1). I guess when I mark them RTBC I can also trigger an 8.2 test (that is already possible to do I think on an 8.0/8/1 issue).

From a testing policy standpoint, we would like the testbots to have differing policies based upon semantic labels, not upon the specific versions.

Myself and Drumm had a bit of a whiteboard session and came up with the following semantic labels for the development branches:

8-stable - This is the current stable release Tag: (8.0.6 currently)
8-supported - This is the current patch level/bugfix branch. (8.0.x, currently)
8-prerelease - This is the label for when a development branch reaches the beta->rc cycle (8.1.x, currently)
8-development - This is where new, backwards compatible feature development is added (8.2.x, currently)
9-development - This is where new, non backward compatible feature development is added.

Anywhere we would display these labels we'd definitely want to have both the label and what they currently point to as part of the display (8-stable [8.0.6]).

As far as where and how to file issues, or backporting policies, I dont believe thats particularly in scope for this issue, other than the fact that it makes those issues easier to discuss if we use agreed upon semantic labels to communicate policy.

+1 for "Anywhere we would display these labels we'd definitely want to have both the label and what they currently point to as part of the display (8-stable [8.0.6])."

I have no strong opinion on the specific labels, but they seem OK to me. And I don't set the issue filing or backporting policies either. :)

The 8.0.6. tag would mostly be for testing purposes when working on contrib modules, I dont think it should be an option for filing issues. Contrib's use case is that when in development, you want to keep all changes isolated to ensure that the only thing that is changing is the code one is actually working on. That is an entirely different requirement than being warned about breaking changes in supported. That's why we want to get to where we actually have different "Job Targets" (development, vs regression) in drupalci - that way patch level changes are tested against something known, and regression tests can catch those kinds of unanticipated breaking changes.

I suppose this needs an IS update.

But if we file/patch/test vs. 8.1 or 8.0 to begin with, then the patch sometimes doesn't apply to 8.2 when it comes time to commit,

Yes, and more than that, as there is no patch for 8.2 at all, the issue simply will not be solved without a patch.

The core issue version should be set to the branch for which we are expecting a patch. Anything else is confusing.
I have checked the last 20 fixed core issues, and every developer is bumping up the version to the latest development branch, where the issue is fixed. So I don't get it why the version should be an "old" release.

I have only found one example where catch moved the version back #2208401: [META] Remaining multilingual migration paths
I think that was just confusing, and did not improve anything. The backport did not happen, and it seems nobody wants it to be backported.
The backport discussion is only meaningful if it happens after the issue is fixed on the latest version. Or a separate issue can be created when it is clear that the backport will need a different solution.

I don't understand what this policy is trying to solve.

@Pasqualle, in most cases there is no "backport discussion" because core policy clearly outlines which issues can be backported and which cannot. A discussion only occurs if there's some potential disruption being weighed against the advantage of having the fix backported to production sooner. The majority of backported issues bugfixes are backported with a simple cherry-pick at the same time as they are fixed in the development branch.

Your sample of the "last 20 fixed issues" is not a good sample, because we were approaching the deadline for the 9.1 alpha, so of course extra attention was being paid to minor-only issues. Not all bugfixes are eligible for backport. I assure you that we create patch releases for both 8.9.x and 9.0.x every month that contain plenty of backported fixes:
https://www.drupal.org/project/drupal/releases/9.0.7
https://www.drupal.org/project/drupal/releases/8.9.7

I also assure you that committers are well-versed in this policy and will backport issues if appropriate. When we're managing 3-4 branches at a time, going through a separate review cycle each time an issue is backported is needless overhead.