Is this issue still outstanding? I looked at the current page and it does not have the content from the wireframe. It also still links "Learn more about Drupal 9" which is about to be two majors out of date.
Six months ago I said this in Slack and forgot to post it to the issue:
I have no issues with the current content, but it definitely needs the sidebar block (possibly with a lot of pairing down and moving some of the direct links to a child level) with our blog and whatnot
Unfortunately I have NO idea what I was talking about. 😅
Clicking fails.
Uhh, we actually already posted this in November 2023.
Actually I don't think the CR should necessarily be for 10.4.x. Maintenance minors should only include four kinds of changes:
- Security and upgrade path fixes.
- Non-disruptive bug fixes that are backported to patch releases.
- Dependency updates and PHP compatibility fixes.
- Important API additions and deprecations for contrib compatibility across Drupal 10 and 11.
This doesn't seem to fall into any of those categories. I think this is probably an 11.1 fix only, since we're making an addition to the default .htaccess?
This is outside our normal BC policy, but has been my strong recommendation for several years ever since Drupal.org switched to making Composer the only recommended way to build a Drupal site. I encouraged @dww to unpostpone the issue because he was asking about a bunch of outstanding maintenance requests related to this dead-end page. (I'm one of the Drupal core release managers, and we have a governance role to decide about technical debt, maintainability, and backwards compatibility questions.)
10.4 should only receive changes that are (a) dependency updates, (b) security or upgrade path fixes, or (c) necessary critical API contrib compatibility. In this case, (c) might apply so that AU only has to take one approach to be added to Drupal 10 as well as 11.
I shared this issue with the other committers to validate my release management recommendation here.
We do need a release note and a CR for it since it's outside the normal BC policy.
Thanks everyone!
I feel certain I have duplicates of this issue somewhere...
This form has been wrong and broken in its behavior since we made the composer improvements in 8.8, and we no longer support any version of Drupal where what it did was correct. Therefore, it can be removed without replacement even without PB existing yet. We just need to make sure PB is not altering it or something.
Unsure about the retitle and IS rewrite here. I didn't say the issue was fixed, just that it was mitigated by a recent change to d.o. The issue is still partly present AFAIK.
Added the idea of just stickying events.d.o to the IS followups.
I put a few notes in the doc. There are nine upcoming events → in Aug-Nov., which seems like too many for a worldwide post. Even if we restrict it to Aug-Oct. there are still seven, mostly in NA. How do we pick which are important enough for international content? Listing four NA camps, two EU camps, and one camp in Asia is also still lopsided and shows an NA bias.
Maybe we should make the post more high-level and include an intro section about Drupal camps in general and events.d.o?
Very nice work @Feuerwagen! Setting NR for review.
Oh FWIW regarding:
Was expected a 1 to 1 for additions to subtractions but see some phpstan things were fixed in the process. Not super clear how adding void to doTestGrouping() fixed those but the checks are all green so won't think too much into it.
If the only thing that's not adding : void is deleting lines from our PHPStan baseline, that's better than good. If there are other changes to actual code, though, that would be something to keep an eye on and document.
Oh also: We can discuss what to do with the leftover methods once the easy/non-disruptive ones are committed. E.g., breaking ResourceTestBase or MigrateTestBase causes pain for a small handful of contributors who are already very active enough to address it quickly, but breaking BTB methods themselves is probably not something we should do in 11.1. So that's the only example where the RC does make a difference, I think. But that's a few lines out of thousands here that we can clean up from the parent(s) once the bulk of the work is committed.
I just mentioned to @longwave that IMO this actually isn't tied to RC at all -- we would want to backport as much of this as possible to 10.3 to cut down on merge conflicts. I apologize for not giving better/clearer advice to start! Hopefully it's just a matter of tweaking a filename matching pattern or two to exclude things called *Base.php or *Trait.php.
Also things with lockfile changes are never good candidates for the friendly bot as they break constantly, and it's not worth rerolling something forever without other progress. So tagging so the bot leaves it alone. Thanks!
Do a better job explaining the dep evaluation and link a couple decent examples (that helped me make RM decisions about previous dependencies).
#2 is still not addressed; this issue could be a whole lot of wasted effort if the dependency doesn't pass the dependency evaluation. I recommend ceasing rerolling/rebasing/etc. and instead completing the dependency evaluation, then tagging it "Needs release manager review" and "Needs frontend framework manager review".
Sorry for noise; somehow either commenting about the CR or closing the MR ended up crediting me for this issue which is not correct. 😂 Fixed now.
@acbramley I assume it was a typo. In this case, a release manager's decision in #30 and #32 that this is too disruptive for a maintenance minor is what stops it from being backported to 10.4.
11.1 and 10.4 ship at the same time, but 10.4 is supposed to have very limited changes per the maintenance minor docs → . But this is the first time we've ever had a maintenance minor and so the committers haven't established a detailed policy yet; we'll learn as we go, just like we did each previous time we improved the release cycle. :)
It's tagged -- thanks everyone!
And yes the "hardcode dates" one is more of a should-have; it's only must-have for 10.4 (but the 10.4 meta isn't a thing on its own ATM due to it being a maintenance minor).
Moving some outstanding thingies to the 11.0.0 meta along with things we should check for again prior to release.
longwave → credited xjm → .
I seem to have invented a patch release in my head.
Discussed with @longwave and @alexpott. It's weird to have a behavior change of any kind in 10.4 and 11.0 but not 10.3 -- 10.4 is supposed to be a maintenance minor that limits disruptive bugfixes, and 11.0 is almost-RC-ish as of the week this was committed. We discussed and agreed the disruption is minimal enough to backport to 10.3.x, which resolves potential 10.3/11.0 parity issues with this API. There is a CR, so the few projects that might be affected can get the info they need.
If this does cause more serious issues for contrib or sites, please open a followup issue linking this one and tag it "Contributed project blocker" if appropriate. Thanks!
Published the CR.
P
Nice find!
For #17 (manual testing with multilingual/localization awareness).
(We might later want feedback from date or localization maintainers to make sure we're using the APIs correctly since it was always sort of a hack and so far this changes the specific format in the hack, but we might also be able to figure that out just from the testing.)
Looks like my feedback from the previous issue did not make it into the IS here.
As I pointed out on the issue that this was split off from, the original date formats were chosen to be reasonably understandable without having to get international localization etc. involved for a status report message, but then trying to mitigate the readability again afterward with the month abbreviation, and I think both might have been wrong. (The original convo went something like: "We shouldn't use an American date format because it could confuse people internationally" "Well, year-first is unambiguous" "Ahh but hmm numbers only are harder to read/scan/understand" etc,
For this issue's change: Why is "2023-Nov-30" okay but not "2023-Nov"?
We should test it in (a) a language that uses the Gregorian calendar but not US date formats and (b) a language that doesn't necessarily use the Gregorian calendar (Arabic or Hindi maybe), and consider a more complete fix.
Updated the release note to explain who is affected.
Fix confusing language that made it sound like security releases were likely to happen outside the windows, and fixed overuse of italics.
Formatting issues and missing branch from security coverage info (did the page get an update from a non-RM? need to check).
Fix missing info about 10.3's release and 10.2's EOL date.
I added the EOL date for 10.3.x, which had gotten deleted somehow. Thanks!
@breezeweb For currently supported versions, the EOL dates are all documented. The Drupal 10 series does not have an EOL date yet because it will not be EOL until at least the release of Drupal 12 or possibly even after. When an EOL date is chosen, it will be documented on the linked page.
See also: https://www.drupal.org/project/drupal/issues/3399348 📌 Template for Core release cycles diagram RTBC
pameeela → credited xjm → .
Updated for the related issue @quietone separated out.
@Chandansha, this is a "Plan" issue, which means we do not create merge requests against it. Instead, we make child issues for the individual tasks with different kinds of fixes according to our scope guidelines. Please don't create merge requests for a single word; furthermore, I would not recommend working on the child issues until we've fixed the plan for them. Thanks!
@quietone raised that this would exacerbate an existing problem we have, in that our list of active subsystem maintainers is not well-maintained and we have a lot of people who have elevated permissions for Drupal core but who are not actually active as maintainers.
This is probably not blocking as it is just an extension of a problem we already have, but it does mean that it would be good to make sure that the granting and revocation of this access is automated, if possible (maybe tied to the "maintain issues" permission on the project node).
pameeela → credited xjm → .
pameeela → credited xjm → .
pameeela → credited xjm → .
pameeela → credited xjm → .
Saving some credits.
Thanks for your patience on this issue.
I discussed this issue at Dev Davs with @catch and @daffie following discussion with @acbramley in Slack.
The new performance is great; however, the downside of the approach currently being used is that it won't work on no-SQL databases. We discussed this with @daffie and he will propose a related issue that will allow core updates to better support an SQL case and a no-SQL case.
We also discussed the proposal to set it to 0 as @Berdir suggested. We're concerned that this could have unintended side effects in edgecases or specific site configurations.
If the data validation allows it to be set to NULL, that would be ideal. Then we can add code that happens on entity save to set a given block's author based on the first revision, so that it happens as-needed rather than in a big batch. So that's the approach we recommend (so long as it is feasible).
Meanwhile, this issue has a data model improvement that should have a change record and maybe a release note. (We'll decide after the final approach whether to use the release note, but having a good release note will help us think about the impacts on site owners, code, etc. as well as edgecases.)
Leaving "Needs release manager review" pending the new approach. Thanks!
The existing date formats were chosen for being reasonably understandable internationally, rather than having to get the date formatter involved for a status report message.
If we want to propose changing that too, I would suggest a separate issue.
@nicxvan, correct, only changes that are disruptive should go in the release notes. The release notes should describe the disruption the site owners or module developers need to address and how.
If it's just an improvement or feature, it should be tagged for the highlights instead.
I don't have time at the moment to look over these three issues, but if they are disruptive, then the release notes should be updated to describe what the disruption is, who is affected, and what they need to do to fix it, with a link to the change record. For more information and examples, see the release note snippet documentation → .
Leaving NR to check back on them.
I think this issue might be a wontfix:
- Having a new required field on every single Drupal site, especially one that does not affect the production user experience, seems like it is fixing an edgecase at the expense of the evaluator and site owner experience for all sites.
- Adding additional form elements always inevitably causes a usability regression, so we should make sure the usability benefit of adding the element outweighs that regression.
- It is also relevant for the product manager role because it affects the evaluator experience of Drupal. Adding an additional thing that must be configured (at site install maybe even?) is a non-trivial increase in the amount of configuration necessary to get up and running.
At a minimum, I think the field should be optional rather than required, and have a sensible default value if the user doesn't provide one. Furthermore, though, this could be addressed with a contrib module and might not even be appropriate for core.
If folks do still feel this belongs in core, then at a minimum, the field should be made optional. Then, that could be submitted for usability review (tagged "Needs usability review") once that change is made. Furthermore, even if the usability team gives the addition a +1 (benefit outweighing negative UX impact), this would still require product manager signoff because it affects the evaluator experience of Drupal.
Also, there is not actually a merge request here ATM, so we would need that too before proceed.
My personal recommendation is actually to mark this wontfix and support it via contrib, but it's outside the scope of my role as a release manager to make a final decision on that myself.
Though the thing with the entity publishing status might be a different, separate issue also.
Per @larowlan ✨ Add view tab + standard template for block content Needs work would resolve this, so maybe this should be closed dupe and its STR incorporated into that issue's summary and test coverage. Postponing for now until I can take a closer look at the other.
I just filed 🐛 Block library view links to the edit page for each content block even when the user does not have edit access Active which may be a duplicate. This issue has wider scope, but would resolve that.
May check back later to incorporate my STR into this issue etc. and properly close it as a duplicate.
Filed the followup: 🐛 Block library view links to the edit page for each content block even when the user does not have edit access Active
xjm → created an issue.
xjm → created an issue.