[policy, no patch] What changes can be accepted during the Drupal 8 beta phase?

I am up for helping visualise this, is it possible to get some pointers during todays sprint.

I do have a few comments coming from Drupal 7 release management were we established a lot of practices.

"What the impacts of making the change are for both core and contributed modules."

• It would be extremely valuable to have a few examples of this. If it linked to precedent that its even more useful.
• Could we consider adding this to the default Core issue template?

"Improvements can be accepted for the following if the issue is critical, or..."

• This seems awfully strong, and quite new to me. Is this agreed upon by all committers? As far as I know, we should continue to improve Drupal even on non-critical issues. There are hundreds of patches (feature, bug, task, etc) that wont negatively impact contrib or core. The main requirement being is that it does not introduce any disruptions, regressions or backlog. If you disallow all non critical/major patches, you are eliminating a extremely large part of our contributor base to core (basically, I cant work on core anymore for atleast year).
• I suggest to follow the; no disruptions, backlog or regressions model and apply that to everything. With a highly skewed focus on fixing criticals/majors but not disallowing anything else. The whole idea of this phase is to allow polishing our parts (we didn't really have a proper polish phase).

For component maintainers that are a lot of things we can do:

• Feature requests shouldn't introduce any backlog, regressions or disruptions. While backlog is often unavoidable, at best it should be followups with very little impact.
• Bug fixes should be highly actionable and contained. More manual testing and a longer timespan to make sure we don't introduce any new issues.
• Critical or majors, should only introduce issue(s) (dependancies) that are manageable before RC1 - its often tempting to exchange one critical for a major. Thats why 7.1 was so fundamental for Drupal 7, because we fixed issues that were kinda critical.
• Educate all your contributors, to get in the mindset of releasing Drupal. This means that they work on the biggest issues in your component, and if possible cross to others were there still are issues. Don't introduce "new" issues. Help them understand, why the quality of a patch now needs to be higher.

The text is a little hard to follow, because the titles are so similar (frozen, unfronzen, mostly unfrozen).

So we have the following situation with #2230637: Create a Language field widget and the related formatter:
Language module currently has a configuration called

Show language selector on create and edit pages

with the configuration key language_show. We realized that this is really an access-related setting and should be applied e.g. during content creation via REST, as well. This would not be an API change in itself, but since are changing the semantics of that setting to be purely UI related the name language_show would be a very bad name. I.e. you would have to configure it when using REST which is not very intuitive.

The issue itself is a critical data integrity bug, but it can be solved without renaming the config name. The question is just whether the criticality also would allow us to change the config name, in order to avoid a really big WTF.

I was confused when I read https://www.drupal.org/core/issue-priority
We need to clarify it, specifically adding task descriptions (and examples) for normal and minor.

And rephrase an item for critical that clarifies removal of a BC layer... means like an entire huge system (not the regular old removal of a deprecated method)

Since that issue-priority page should really only be changed by maintainer agreement, commenting here.

I tried applying this to the set of issues:

• #2350807: add getId() and make id() a wrapper for it and deprecate it
• #2246695: replace all core usages of id() with getid()
• #2350827: remove deprecated id()

Please see if I have used this policy pattern correctly.

So I propose to revamp this a bit, because the whole (frozen, unfrozen, mostly frozen) part really confuses me. There are a few things we can optimize:

- Clearly distinguish the requirements to meet on top
- Separate out advise how to handle "non applicable" changes from the advice on what is allowed. So separating "qualifications" from "how to handle it in the queue".

My lullapad is here, it has quite an impact so I didn't update the sumaary (as advised by xjm). Part of this is the fact that our titles are not different enough but its also organisation.
https://pad.lullabot.com/p/i2ZYa2g6MR

...Oct. 27 (which will be the commit freeze prior to the tagging of 8.0.0-beta1)...

This should be a typo right? beta1 is already tagged. I took the liberty to change it to beta2...pls correct me if I'm wrong.

Great write up @xjm, thanks.

I know it's understood amongst most contributors but it would be nice if this policy mentioned that "new features" or non-critical migrate patches will still be committed during beta as not to confuse or discourage new contributors from working on migrate patches?

@benjy I updated the issue summary for migrate - does that look OK?

@catch, yeah that's great. Thank you.

The backwards compatibility section of this is hard to apply consistently. Discussed with Alex and we think the following might be OK.

This should only apply where we think there's a decent chance of contributed modules getting affected, not for dead code. Also we can reserve the ability to break modules early and explicitly due to a critical issue. Additionally it only really applies for new deprecations of functions that weren't previously.

The idea we came up with is to support contributed/custom modules that are porting against each beta release.

What we should try to avoid outside of exceptional circumstances:

Module ports to beta 1, function is not deprecated.

Module ports to beta 2, function is removed, BOOM!

The wording would be like this. This assumes we are currently at beta 1, the patch goes in before beta 2 is cut.

@deprecated in Drupal 8.0.x-dev, will be removed no earlier than Drupal-8.0.0-beta3 and before 9.0.0 use blah instead

This means:

Module ports to beta 1, function is not deprecated.

Module ports to beta 2, function is deprecated - has ability to update without fatal errors.

Module ports to beta 3 (or later), function is removed, already updated so doesn't care.

I worry that direction could lead to more "nice to have" refactoring and not more getting the release out the door sooner, which is what we need to be focused on at this stage. It also (at least potentially) leads to us needing at least one extra beta we wouldn't have otherwise have needed in order to give people the opportunity to see a function's deprecated before RC. (EDIT: And also creates issue management headaches, because you need to mark an issue fixed, then... postponed? Then somehow manage to find them later to remove the dead code in time. More time/energy/attention/focus diverted away from getting D8 out the door. :\)

If we didn't manage to mark a function deprecated in 3.5 years, why can it not live until D9?

"If we didn't manage to mark a function deprecated in 3.5 years, why can it not live until D9?"

That's just for the function itself, btw, as a BC wrapper. In 8.X.x we could happily be removing procedural cruft from the core code base, marking things deprecated, and converting all of core's code to use OO goodness instead, and recommending such in the release notes. I just feel strongly we need to stop doing that now, when we're staring down an ever-growing pile of critical bugs standing between us and D8's release.

So I proposed a rewrite to make things more clear, I am not sure if thats still being considered or if my work there was moot.

@catch This is not usually something I comment on at all, and was very hesitant to do so. But I am very worried about all the strategies that seem to impact our ability to release. I don't feel like there is the same urgency, to release Drupal 8. While we don't have much market analysis, I feel like much of our momentum is flattening - having Drupal 8 out the door is monumental and key to our larger ecosystem.

Rules should be evaluated whether it helps us getting closer to a quality release. I don't feel that there is the same urgency amongst comitters, and that is worrisome. We already communicated to people that during beta, we might change critical things - contrib maintainers are aware of this and know this from our previous releases. We already communicate very clearly that removing/deprecating API's should by large apply only to major/critical issues. I feel like most of the management in between beta releases, has very limited value in the large scheme of things - and ideally we wish to compel those contrib maintainers to be somewhat aware of core, and ideally even move between the contrib and core queue.

@Bojhan I would suggest making your changes directly in the summary here... it makes a nice diff people can review, if they feel like it changed meaning (instead of just making things more clear). I say this, because I thought that your re-write got feedback from xjm and others during AMS...

@catch I know you mean well with the removal of functions. But I think as a module developer do it like the removal of a band-aid: quick and fast!

Is it possible to get a list of function, per beta release, that where removed since the last beta release. That will make it more easy the solve bugs that are the result of the removed functions. Just an idea.

@webchick I'm thinking of issues like #2350437: Mark unicode.inc functions as deprecated where the refactoring was done weeks/months ago but we just forgot to mark the wrappers deprecated.

Or #2350949: Add hook_page_attachments(_alter)() and deprecate hook_page_build/alter() which is critical, but where there's disagreement on the issue as to whether to leave a BC layer in at all or not (see Moshe's comment) and where it's not just a wrapper - in fact that's the main reason that critical issue isn't RTBC at the moment.

In both of those cases it's not extra refactoring, but stuff we would/have done anyway and handling the impact on modules.

With the last beta - if something gets marked deprecated then, we can just leave it deprecated until 9.0.x, no need to put out another beta.

I'm also fine with leaving things in if there's no good reason to remove them and the band aid approach that @daffie said, but since we'll need to remove some cruft, and deprecate some things, trying to come up with some consistent policy seemed better than having to individually communicate and discuss on every single issue that does this which course of action to take - which also takes energy away from getting the release out. Especially when it's critical issues that are either adding BC layers we don't want, or taking out BC wrappers we might want - lack of consistency makes it harder to work on/review/commit those issues and we can't just pretend we don't need to deal with it.

Moving this to RTBC - we can always open a side-issue to sort out deprecations further, but I think there's pretty broad agreement on the issue summary itself. Will need transferring to the handbook before we mark fixed. Also most of this was discussed with Dries in person before it got written up/refined but assigning since he hasn't commented here yet.

I guess it's fine, since all of the "insiders" have seen it (well, 26 of them anyway), but one thing we never did was inform the wider community of this proposal. A post to g.d.o/core was blocked on a diagram and example issues, which are still listed as "forthcoming."

I guess we can inform the wider community after the fact of this being approved, but I have doubts that all of the people we want to have seen this proposal actually have seen it given the types of issues I'm still seeing being worked on right now.

There are example issues in #12.

#2070737: Change values of LanguageInterface::DIRECTION_(LTR/RTL) to ('ltr'/'rtl') also has some discussion. That might be enough to write some things up, not sure.

I'd be OK with a g.d.o/core post while this is RTBC for final comment, but diagrams made by me are unlikely to make this clearer and we're already applying the policy to patches - so the longer it's in an issue and not in the handbook/g.d.o/core the more confused people who haven't seen it will continue to be. We really should have had this written up before the beta was tagged, but that didn't happen.

I am really not sure about the way this information is presentable. Its quite hard to grok. I'd love if we take another stab at visualising and rewriting this.

Compared to the previous documentation we had for Drupal 7 its cycles, this is far less usable for new people to understand what is going on. Webchick her blogposts were always quite useful in understanding. Lets see if we can learn from that previous communication.
- My rewrite: https://pad.lullabot.com/p/i2ZYa2g6MR
- I am happy to help visualising, but frankly not sure if I should input more work, considering the fact that my lullapad wasn't looked at.

Marking this tentative, to needs work. Since this mainly about the "how" not the "what" of communicating this.

@Bojhan I didn't know there was a lullapad :( Looking now.

I've moved the lullapad to the issue summary, that's much clearer.

All the stuff that is in the issue summary is all very theoretical. What I would like to see is what that means for the individual issues out there. Can the four core committers decide for the individual issues whether they are going to be included in Drupal 8.0.0 or that the issue is going to be postponed until Drupal 8.1.0 or 9.0.0. I know this will make a lot of core developers not very happy. But at the moment there a lot of issues being worked on that are for instance beta-target. And I think that if we want a speedy release of Drupal 8.0.0 that some or a lot of those issues need to be postponed until after the release of Drupal 8.0.0.

Can the four core committers decide for the individual issues whether they are going to be included in Drupal 8.0.0 or that the issue is going to be postponed until Drupal 8.1.0 or 9.0.0.

No, there are five core committers, and over 4,000 open issues against 8.0.x. The point of the issue summary is to give a framework so that people can figure out themselves whether an issue is eligible or not.

Since the issue summary now contain's Bojhan's rewrite, moving back to CNR.

For most of the issues it is clear if they are allowed for Drupal 8.0.0. But there are a few issues that can be argued pro and con. If the five core committers can decide those issues then all other issues will clear what their status will be. It will make this policy concrete and clear to everybody. So that we all can concentrate and work to releasing 8.0.0.

@daffie issues that are borderline and people can't figure out themselves, they can ping one of us for feedback - but see the notes regarding issue summaries etc.

@xjm Thanks for the new flowchart - super clear and easy to grok.

We need to discuss removal of deprecated functions. Eg.

• #2361823: Remove usage of drupal_strtolower()
• #2358999: Remove usage of drupal_html_to_text()
• #2353013: Remove taxonomy_term_load_parents_all from taxonomy/taxonomy.module

Those are currently the oldest 3 issues in the rtbc queue. And they are all normal tasks - which I think is the correct status.

Considering that these patches are removing usages of functions that we've deprecated in previous patches I think that we should be committing these patches under the aegis of either a new category of prioritised changes or under "follow to a recent critical or major". Unfortunately we can not be sure that the function was deprecated by a critical or major or was actually that recent. So I think we should add a new category of "Removal of functions and methods that we have documented will be removed prior to 8.0.0".

If we do not want to do this the only alternative is to file an issue to change the deprecation of all the functions to 9.0.0 - which I think is silly. One reason is that this is a finite piece of work if we also agree that we will not (unless necessary) mark any more functions for removal prior to 8.0.0 - I think we have already tacitly agreed to this by calling the beta. Another reason is we've said we are going to do this and already agreed to it. Lastly, this issues remain a good entry point for contributors and many of the existing issues have work from people new to contribution so as a first experience it would suck to say well we said this then but now we're going to make you wait x years.

+1 For removing the deprecated functions. Module developers know or should know that these functions will be removed in 8.0.0. So lets remove them.

So I think we should add a new category of "Removal of functions and methods that we have documented will be removed prior to 8.0.0".

+1

However, I think that category should still point to the "impact > disruption" box. Something like #2353013: Remove taxonomy_term_load_parents_all from taxonomy/taxonomy.module seems like an obvious yes to me, as it causes no disruption. However, #2361823: Remove usage of drupal_strtolower() changes ~100 hunks of code, so might require rerolling lots of other core patches, but that's mitigated by each such reroll being easy. So I could see something like that needing a judgment call by the committer.

However, I think that category should still point to the "impact > disruption" box.

+1 and if we put it in the "prioritised change" list then it already does :)

The issue summary looks great to me. Just a couple nits:

external PHP and asset library updates

This is in the summary text, but not in the diagram footnote.

If a change can be accepted based on the criteria above but introduces a backward compatibility break, the patch for the issue should also provide a backward compatibility layer if feasible and where the BC layer would not introduce significant technical debt, or where the API is sufficiently new that there is no likely chance of it having any consumers anywhere.

Awkward grammar: does this mean that if the API is sufficiently new, then a BC layer should be or should not be provided?

This looks great to me! Excellent work, xjm and team. Approved.

We need this in the handbook before calling it fixed, per #29.

https://www.drupal.org/node/2368133

What happened to the nice diagram being part of the issue summary?

@jhodgdon I still see the nice diagram... maybe internet hiccup?

I think we need to add changes to individual theme functions to 'unfrozen' - since that is:

1. Necessary to make markup changes (for anything that's not already a template)

2. By definition low-impact unless it's extremely commonly used

This came up for #1938918: Convert menu theme tables to table #type which I'm about to commit based on that (if we don't add it to unfrozen, I think that issue would still be OK on impact > disruption.

yeah, flowchart is back, must have been a hiccup indeed! who knows.

It sounds like this should still be open for #66/#69 (or is that already resolved?).

I also just came across this stuff, and really like the diagram but I see two problems:

1. There is no provision for issues that are backportable to Drupal 7. That means that any Drupal 7 feature requests (and possibly some non-features too) that aren't in Drupal 8 yet will be held up in waiting, potentially for a very long time. There are only two issues in this state currently but I would expect more as additional issues get recategorized for 8.x-1.x or labeled for backport properly.

   I think in practice, allowing these kinds of issues into Drupal 8.0.x will not cause delays in the Drupal 8 release (pretty much by definition they fall into the impact > disruption category) so I would argue for just accepting them and seeing how it goes.

   Suggestion: New orange box at the top, "Backportable to Drupal 7" => "Proceed"

2. The "Postpone" wording is confusing. Some people are taking that literally (currently around 60 Drupal 8.1.x issues marked with the "Postponed" status) though in more cases they are not. I think there's no reason to mark an issue postponed if it's already moved to 8.x-1.x; usually there is nothing actually blocking someone from working on it (even if it won't be committed for a while). I think that's consistent with how this was always handled in the past also.

   Suggestion: Rename the "Postpone" bubble to "8.1.x or later", and clarify in docs that 8.1.x and 9.x issues don't need to be marked postponed

The action we want people to take is to both move it to 8.1.x or 9.0.x *and* mark it postponed.
We do not want people working on these things.
Those branches are not open for development yet, and are available to choose in the issue drop down for a version for bookkeeping only.
This is a change from how releases were managed before.

This will help new people be able to find issues to work on that are relevant now, and more likely to get feedback and reviews. (8.1.x and 9.0.x are not those. some of them have work already, and have lots of comments, so without the clear postponed on them, people may not realize that they should not be worked on right now)

https://www.drupal.org/contributor-tasks/update-allowed-beta
lists those steps also (change the version and mark it postponed, and add a sentence as to what it is postponed on: the opening of 8.1.x for development). If I am wrong, and we want to non "postpone" the issues... then that contributor task doc should also be updated.

As a contrib module developer I use drupal core as a reference how problems are solved. I follow the issue queue to what is still to be solved with a different solution. After an issue is landed I can check if I need to update my module. If open issues that I follow for my contrib module are changed to postponed to 8.1.x or 9.0.x, I know what the drupal solution is for a particular problem. I know that that does not mean that is the best solution. And I try to understand what the issue is about and why the drupal community chose the solution that it chose. And how that will effect my contrib module. But still for me and a lot of other (contrib) developers drupal core is the reference solution for the way (contrib) modules should be programmed.

So, I read #16, but where does that leave coding standards?
I know for things like "get X module/component to pass coder review" we are postponing those (not on 8.1.x or 9.0.x, but on having our testbot automatically test for things). See #1518116-86: [meta] Make Core pass Coder Review

But what about more scoped things like the children under #2052421: [META] Rename Views properties to core standards like #2078593: In WizardPluginBase Rename Views properties to core standards are those also postponed under not meeting the criteria here and/or postponed on automatic tests for them?

The action we want people to take is to both move it to 8.1.x or 9.0.x *and* mark it postponed.
We do not want people working on these things.
....
This is a change from how releases were managed before.

Interesting... I am wondering if this was discussed anywhere? (I don't see a specific discussion in this issue.)

I see the point, but the downside is that issues tend to get forgotten after being postponed (someone could certainly go through all 8.1.x issues and unpostpone them later, but doing that quickly in bulk would result in some being unpostponed that shouldn't be, since they might also be postponed for another specific reason - i.e. a dependency on another issue that isn't complete yet). I can see this causing problems later on, or at least causing a lot of work unless the issue summaries are really perfect.

Also, there are good reasons to work on patches sometimes even if they can't be committed until a future release (rerolls to keep them fresh and not get too out-of-date, bigger issues that might take some planning and even patching in advance, etc). To get the testbot to run on such an issue you would need to move it out of "postponed" status anyway, I think.

Ideally I would expect the "8.1.x" version should indicate to everyone that it's not immediately relevant and won't be committed until that branch is open (even if it reaches RTBC status way before then) though I understand how the word "postponed" at the top of the issue page makes that more clear.

I agree with David. Marking an issue "postponed" and moving it to 8.1.x seems like overkill. People are going to have to get used to there being multiple 8.x. versions.

regarding #1921152: META: Start providing tour tips for other core modules. (meta is a normal task, and so are the children)
Can we confirm task issues that add tours is allowed?
I think maybe under the list of unfrozen allowed changes?
They are documentation (like): most adding tour yml, maybe a tour test, and css (or adding a css class into code to be used by the css).
@larowlan mentioned in irc remembering that @alexpott said tours could be committed up till string freeze.

and want to confirm that #2016679: Expand Entity Type interfaces to provide methods, protect the properties and all of its children should be postponed? (ug. I dont look forward to explaining to php people why we use public properties as an API instead of methods)

wait... in #2030645-31: Expand Menu with methods @alexpott reclassified it as a bug. phew.
will do that for the meta and the children.

Re #77/#1921152: META: Start providing tour tips for other core modules. I think adding tours should be allowed since as YesCT has pointed out it is adding documentation (tour yml), CSS and a test all of which are currently allowed. Additionally adding tours is very low risk and will benefit users.

Yeah I think postponed is OK for 8.1.x and 9.x. We might open them a month or so before 8.1.x actually opens for development (no real point branching until there's an RTBC patch to commit to that branch), but this will be after 8.0.0 is actually released.

Some issues are also blocked on other patches, but that can be handled with parent/related issues and issue summaries (and we aren't great at doing that consistently with postponed anyway).

Leaving this open for the remaining discussion, but demoting from critical - I don't think any of these details are blocking, but having proper documentation in the first place was.

Also I added a note about 'bugs and tasks that need to be backported to Drupal 7 and/or Drupal 6' to prioritized items.

I agree with xjm that any new feature for 7.x should have to follow same rules as if it was only going to be added to 8.0.0 and not backported, unless it's something that doesn't need to go into 8.x first anyway.

Regarding backports, I think stuff that needs backport to D7 should fall under the "prioritized categories" already?

I think this is probably true for bug fixes and tasks (and now it's official based on @catch's change to the documentation). But not for features since the diagram says to postpone those no matter what.

Since Drupal 8 has been in feature freeze since Dec. 2012 and over feature issue thresholds for longer...

Technically, yes, this backport problem should have arisen in 2012 rather than now :) But in practice tons of features have been committed to Drupal 8 during that timeframe anyway: https://www.drupal.org/project/issues/search/drupal?status[]=7&categorie... (not all of those are actually closed due to a recent commit, and not all of those are actually features despite being labeled that way, but quite a few are)

I assume that with the Drupal 8 beta and especially with all the effort to define what can go in during the beta, means this really becomes strict now.

Essentially this is a new problem (since Drupal 6 was never really open for features post-release). Accepting new features into the current stable release but having more stringent criteria for getting things into the unstable branch doesn't make a whole lot of sense to me and also effectively blocks things from getting into the stable release. Given that new features for Drupal 7 are generally pretty small and have to be reviewed very carefully and meet stringent criteria (essentially, "don't break anything") I think it would be reasonable to still accept features into 8.0.x that meet those criteria, as long as they are backportable also; it shouldn't cause much disruption.

---

I disagree with this because no issue that gets to "RTBC" against 8.1.x will be committable by the time 8.1.x opens. (We've discussed that 8.1.x won't even open until 8.0.2 or so; we are talking more than six months and probably at least a year. Core now won't resemble core then.)

I don't think it's unusual for a patch against a stable (or almost stable) release branch to go months or even years and still apply afterwards, or at least apply with a small reroll.

The branch isn't open for development and in a sense it hasn't even really been branched yet. It is not maintained with 8.0.x; it is months stale now... Expecting contributors to know that we will only look at 8.0.x now, and that 8.1.x isn't really open, and that even if they created patches for 8.1.x they would need to use the 8.0.x branch in git for the newer branch tip,

That is a good point. I was not thinking of the 8.1.x branch that way at all, but now that I think about it, it's obvious that 8.1.x must be out of date :) Yes, I can imagine that confusing people. Perhaps it would be good to replace the whole branch with a README.txt file (and then delete and recreate the branch later when it's open for real)... Although presumably this same issue has occurred every time in the past that a new Drupal core branch was created.

I don't feel particularly strongly about not postponing 8.1.x issues, but I think it's unlikely to be applied consistently (especially with people creating new 8.1.x issues all the time) and there's potential for confusion with that also.

Did not mean to change the status. I think I had this issue open in a tab in my browser for like 3 days in a row so it was very stale :)

@David do you have a specific Drupal 7 feature in mind that you think ought to still be able to get in to Drupal 7, but would be blocked on 8.0.x?

Well, the two issues in the list I linked to before (there are still only two of them) both look like they would be useful for Drupal 7 if people work on them:
#299138: Improve \Drupal\Core\Utility\Mail::htmlToText()
#2212323: Make a way to better control search result display

For others that have not yet been bumped to 8.1.x (but are currently tagged as feature requests for 8.0.x so if that sticks they will be bumped), here's the full list of those that are also currently marked for D7 backport:

https://www.drupal.org/project/issues/search/drupal?project_issue_follow...

It's a pretty large list.

Skimming through it, here's a few that caught my eye that seem quite likely to be actually backportable to Drupal 7 and that wouldn't necessarily require tons of effort or be incredibly disruptive either:
#1862094: After installing a theme, display a link to "install another theme"
#1252606: Add crop anchor option to Scale and Crop image effect
#1067620: Add Description text for image fields
#205515: Usability: Link to the next new comment
#1370346: Add apostrophe as thousands marker

we did add any issue tagged "needs backport to D7" to the prioritzed changes for the beta per David's comments.

Hm, that's definitely good, but I think it applied to bugs/tasks more than features - the big issue is that "Feature? Yes => Postpone" was still at the top of the diagram at https://www.drupal.org/contribute/core/beta-changes.

In practice I'm not sure how much this mattered in the end since very few features actually got formally bumped to 8.1.x, but it probably had an effect. I think we should consider changing this in the future (if the diagram is still relevant then) and will create an issue for that.

Going forward, we should discuss if we can also adopt semantic versioning (or something similar to minor versions) for Drupal 7

Currently under discussion at #2135189: Proposal to manage the Drupal core release cycle although might be moved to a separate issue.