Problem/Motivation

We need some new releases. Let's figure out a plan.

  1. I think it'd be wise to sort out #2418369: Internal URL handling (language prefixes, base://, ...) and #3270030: 8.x-1.0-alpha3 breaks images in multi-language sites. before we really call this "stable".
  2. It'd be nice to finally release a 8.x-1.0 stable release for folks getting nailed by those issues that are still stuck in D8 or D9 land. Once those are resolved, we could move to 8.x-1.0-beta1 or even rc1 or something.
  3. It'd be good to do whatever big overhauls we're wanting as part of the 2.0.x branch before we release 2.0.0.
  4. Maybe we should put out a 2.0.0-alpha1 "now" with just the D10 compatibility and all the known bugs from the 8.x-1.x branch.

Proposed resolution

Each subsection includes the issues that must be fixed before the corresponding release.

8.x-1.0-alpha5

If these 2 test-only changes are all that we do, there's nothing user-facing that would justify a new release.

2.0.0-alpha2

2.0.0-beta1

Best effort

(not a requirement for any release, but we'd like to fix them "soon")

Released

8.x-1.0-alpha4

https://www.drupal.org/project/pathologic/releases/8.x-1.0-alpha4

2.0.0-alpha1

https://www.drupal.org/project/pathologic/releases/2.0.0-alpha1

Remaining tasks

  1. Actually decide on a plan.
  2. Do the work.
  3. Create the releases.

User interface changes

API changes

Data model changes

Comments

dww created an issue. See original summary.

mark_fullmer’s picture

mark_fullmer
he/him
Primary language English
Location Tucson
commented

Two quick roadmapping/planning thoughts!

1. We've started adding multilingual test coverage in #3270030: 8.x-1.0-alpha3 breaks images in multi-language sites.. That test coverage should probably be in place before we sort out #2418369: Internal URL handling (language prefixes, base://, ...), and maybe #3157085: Convert tests/src/Functional/PathologicTest.php to a Kernel test should be done before that, in case conclude that we can include multilingual test coverage in the Kernel test.
2. We could stet a target date for putting out 2.0.0-alpha1 (which would include jsut the D10 compatibility work already merged into 2.x) so that folks waiting on that to land for Drupal 10 updates can plan better.

dww’s picture

dww
we/he/they
commented

Great questions, thanks!

  1. Yes, those all seem like the top priorities to me. My preference would be to improve the tests before we do much else. 😅
  2. Sounds good. The big question is should we already revert #2692641: Convert href to the aliased URL if possible or not before we tag alpha1. Maybe 2.0.0-alpha1 that's exactly as broken on multilingual as 8.x-1.0-alpha3 is better than waiting for the dust to settle on all the issues in point 1? But part of me wants to fix point 1 before we make any more releases at all...

Meanwhile, there are currently only 7 open bugs for 8.x-1.x and 2.0.x, and one of them is postponed on getting more info from the reporter. Two of those are from point 1. That leaves only 4 real open (modern) bugs that we know of:

It's possible there are some real bugs still lurking in the 7.x queue, but I haven't spent any time trying to triage all that.

Haven't started triaging 8.x/2.0.x task issues, but that's next on my list for this roadmap...

dww’s picture

dww
we/he/they
commented
Issue summary: View changes

Taking a look at tasks...

These are the ones I care about:

Then we've got a few that mostly seem like busy-work issue credit farming (a bunch of different users all "contributing" 1 patch, usually insufficient, and then disappearing):

It would be nice to have phpcs happy and reporting no errors, but IMHO not worth holding up releases over any of these...

- - - End of Triage - - - 😉

So, I think the next step is to update the summary with a specific draft proposal of blockers for each of our next few releases.

TL;DR: The "modern" queue is actually in better shape than I feared. 😅 Only ~4 bugs and 2 tasks that really "Should" happen in the near future...

dww’s picture

dww
we/he/they
commented

Very quick skim of the 7.x open bugs:

  1. There are 20 issues to triage
  2. Only 1 has been updated in the last 2 years. For most, it's been more like 5-8 years. 😅
  3. The D7 vs. D8/D9 codebase is pretty similar, so I'm assuming some of these are actually still valid.
  4. Only 4 have had any real work done (2 NR, 2 NW), everything else is lingering in "Active".
  5. If no one cares about any of these, I'm happy to close them as "outdated" or something, and invite anyone who does still care to open new issues for 2.0.x with modern steps to reproduce, etc.
  6. That said, if anyone is inspired to do a more thorough triage and try to reproduce anything in the modern versions, that'd be most welcome. I just don't have the bandwidth for that right now...
mark_fullmer’s picture

mark_fullmer
he/him
Primary language English
Location Tucson
commented

TL;DR: The "modern" queue is actually in better shape than I feared. 😅 Only ~4 bugs and 2 tasks that really "Should" happen in the near future...

Woohoo! Feels manageable!

I'd done something similar to #3216612: Remove usage of "whitelist", use better terms instead in Layout Builder Restrictions' #3179983: Replace remaining language of 'whitelist'/'blacklist' in Layout Builder Restrictions module, which also involved "API changes," so I've assigned myself to that issue.

mark_fullmer’s picture

mark_fullmer
he/him
Primary language English
Location Tucson
commented

The big question is should we already revert #2692641: Convert href to the aliased url if possible or not before we tag alpha1. Maybe 2.0.0-alpha1 that's exactly as broken on multilingual as 8.x-1.0-alpha3 is better than waiting for the dust to settle on all the issues in point 1? But part of me wants to fix point 1 before we make any more releases at all..

After thinking about this a bit, I think we should revert that change before doing the 2.0.0-alpha1 release, under the reasoning that it's a behavioral change in how the links are rendered that affects all sites, even if it only *breaks* things on multilingual sites.

dww’s picture

dww
we/he/they
commented
Issue summary: View changes

@mark_fullmer:

#6: Thanks for taking #3216612 forward! Agreed the queue is manageable.

#7: Yeah, good point. So I think we really do want to finish up point 1 before point 2.

Updated the summary with a 1st draft on a release plan. Thoughts?

Thanks again!
-Derek

dww’s picture

dww
we/he/they
commented
Issue summary: View changes
dww’s picture

dww
we/he/they
commented

@mark_fullmer: p.s. I pinged you in Drupal Slack to try to discuss some of this in real time. Are you ever on there? Lemme know. Thanks again!

dww’s picture

dww
we/he/they
commented

p.p.s. I did some initial minor updates to the project page to reflect reality in 2023. 😅 More help needed there, but it's a start. Part of that was marking the 7.x-2.x branch unsupported. 😂 I did leave 7.x-3.x both supported and "recommended" (for the sake of the core Update Manager), but I'm not planning to support it unless someone wants to fund my time to do so...

mark_fullmer’s picture

mark_fullmer
he/him
Primary language English
Location Tucson
commented

This release plan is a great outline for, really, the extant outstanding work for this module, and provides a steady, manageable update path from 8.x-1.x to 2.0.x.

Should we create a separate issue to plan to add the "deprecated" lifecycle key at some point in the future to the 8.x-1.x branch, to help folks still referencing "^1" via Composer. Possibly that change could be timed with the 2.0.0 release.

In any case, this is a great working model for the next tasks. Thanks!

dww’s picture

dww
we/he/they
commented
Issue summary: View changes

Great, thanks. Crossing off “decide on a plan”. Now we’re down to “do the work” 😅

That lifecycle key isn’t meant for dropping support on older versions of the same module. It’s mostly for cases when we’re removing modules from core, or if you’re otherwise deprecating one module in favor of another. We can just mark the 8.x-1.x branch unsupported at a certain point.

Also, since this module doesn’t really provide much of an external API, and the upgrade from 1 to 2 will be very easy, I don’t think we need to worry too much about alerting users they should upgrade.

rajab natshah’s picture

rajab natshah
he/him
commented

Tested the dev version. Good to release.

svendecabooter’s picture

svendecabooter
he/him
Primary language Dutch
Location Gent
commented

I am also in support of adding a new alpha(?) release with D10 support, so sites can move along with the migration to D10. The remaining bugs are already in the 8.x-1.0-alpha3 release anyway, so at least it doesn't block a D10 upgrade.

gravelpot’s picture

gravelpot commented

Good morning, I'm here to add my voice in support of a D10-compatible release. An alpha or beta release would be fine, just something other than a dev build, since we have recently run into a technical limitation using a dev build based on a specific commit hash. We found that you can't rely on getting the same thing every time you do a Composer build without modifying the site's root `composer.json` file, which isn't an option for us with the architecture of our Pantheon custom upstream.

We are on schedule to upgrade ~100 sites from D9 to D10 in May, and this is one of the last remaining contrib modules in our standard distribution that does not have a D10 compatible release. I appreciate all the fine work folks are doing here, and hope this can get pushed over the finish line soon. Please let us know if there is any further labor that can be contributed to the effort in specific issues.

dww’s picture

dww
we/he/they
commented
Issue summary: View changes

Some updates to the plan per the discussion w/ Mark referenced at #3270030-35: 8.x-1.0-alpha3 breaks images in multi-language sites....

Meanwhile, the 2.0.0-alpha1 release should be out in a few hours.

dww’s picture

dww
we/he/they
commented
Issue summary: View changes

Refresh the plan to add a "Released" section now that the next round of alphas are out. 🎉

mark_fullmer’s picture

mark_fullmer
he/him
Primary language English
Location Tucson
commented

Yehey for the Drupal 10-compatible release!!! 🎉 🎇 🎋 🎏 🧧

dww’s picture

dww
we/he/they
commented
Issue summary: View changes

Adding a note that at this point, we have nothing user-facing for 8.x-1.0-alpha5, so it's not really worth another release there, even though all the planned issues are now fixed. 😅

I'm still trying to sort out if #2718473: Dynamic routes in image styles break under pathologic is duplicate with #2418369: Internal URL handling (language prefixes, base://, ...) or not. 😉

dww’s picture

dww
we/he/they
commented
Issue summary: View changes

Adding #3362585: PHP 8.1 deprecation notice for passing NULL to explode() to the lists...

abu-zakham’s picture

abu-zakham commented

Hello,
Thank you for your dedicated efforts!

Could you please release version 2.0.0-alpha2? there is five issues fixed on dev.

dww’s picture

dww
we/he/they
commented

Yes, but 4 of the 5 are test-only fixes. That doesn't seem worth troubling everyone with a new release about. 😅 Only once we fix some more user-facing stuff is it worth a new tagged release (IMHO).

Thanks,
-Derek

rcodina’s picture

rcodina
Primary language Catalan
Location Barcelona
commented

@dww I think now It's worth to release a new version 2.0.0-alpha2 which will include #3388563: Option to keep language prefix in URLs and PHP 8.1 fixes. I'm forced to temporally move this module to modules/custom folder because my customer doesn't allow dev versions on their composer.json and we need the language prefix fix.

dww’s picture

dww
we/he/they
commented

@rcodina: Good point. I pushed a 2.0.0-alpha2 tag, the pipeline was happy (happy enough 😅), so I created the release: https://www.drupal.org/project/pathologic/releases/2.0.0-alpha2

Thanks,
-Derek

rcodina’s picture

rcodina
Primary language Catalan
Location Barcelona
commented

@dww Thanks!

dww’s picture

dww
we/he/they
commented

FYI: https://www.drupal.org/project/pathologic/releases/2.0.0-alpha3 is now out, with the only change being D11 compatibility.

dww’s picture

dww
we/he/they
commented
Assigned: Unassigned » mark_fullmer
Status: Active » Needs review

I'm having 2nd thoughts about this plan. 😅 I don't have consistent time/sponsorship to deal with this module. Happened to spend a few hours today to clean up a bunch of things:

Meanwhile, nearly 10K sites are running the 2.0.0-alpha3 release. Seems pretty stable to me. 😂 Sure, there are some known bugs. But it's sad folks have to set minimum-stability to 'alpha' to use this. More seriously, even though input filter modules are potentially some of the most dangerous you can install, since we're still at alpha, we're technically not even covered by the security team. 😬

For years, I've been a perfect-is-enemy-of-good style maintainer, and leave things as "alpha" for years since my hyper-perfectionist self isn't happy yet. 😢 But I'm trying to move past that. I'm strongly tempted to simply tag a 2.0.0 release in the near future. Our user base will rejoice. We'll actually be providing security coverage.

For these serious known bugs:

let's aim to fix those in 2.0.1 if they seem fixable with minimum disruption, or bump to 2.1.0 if needed.

Assigning to Mark for review, to get a sanity check on this before I go wild-west with it. 😂

Thanks!
-Derek

mark_fullmer’s picture

mark_fullmer
he/him
Primary language English
Location Tucson
commented

Thanks for this thoughtful perspective, dww. I think the crucial thing you identify is the problem for integration with:

But it's sad folks have to set minimum-stability to 'alpha' to use this.

I've also heard from some community members that their organization won't allow them to use a module that is tagged alpha as a policy, regardless of what other indicators of stability say.

The other benefit you point out is the ability to opt in to Drupal security coverage.

I fully agree that this is an instance where the Pragmatic Programmer principle applies, and we should move ahead with a 2.0.0 release.

Right now, the 2.x branch is compatible with Drupal 9 and 10. Eventually -- e.g., when we adopt OOP implementations of hooks and switch from Doctrine Annotations to PHP Attributes -- we'll have to drop support for D9 and some versions of D10. But that's totally acceptable to do in a minor version release, per https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or...

So yes, full steam ahead with 2.0.0!

mark_fullmer’s picture

mark_fullmer
he/him
Primary language English
Location Tucson
commented
Status: Needs review » Reviewed & tested by the community
dww’s picture

dww
we/he/they
commented
Assigned: mark_fullmer » dww

Cool, thanks! I'm totally slammed this week, but I'll try to get 2.0.0 out Soon(tm), perhaps early next week.

dww’s picture

dww
we/he/they
commented
Version: 2.0.x-dev » 2.0.0
Assigned: dww » Unassigned
Status: Reviewed & tested by the community » Fixed

https://www.drupal.org/project/pathologic/releases/2.0.0 🎉

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.