[META] Roadmap for stable

@geek-merlin I'm a bit confused here - you seem to have deleted all the issues that I originally put in. Perhaps your idea is that they are contained with the link to all RTBC patches? I'm not so sure about that direction.

1. I had added a sentence for each issue explaining why it is important and now that's lost.
2. Patches can stop being RTBC, for example if someone (not necessarily even anyone who has any relevant expertise) makes a trivial objection. Conversely not every issue marked RTBC is necessarily important or even valid.
3. The RTBC patches are likely the most important, and now they the least visible. Instead the reader will immediately notice the other issues you actually listed.

Surely the whole point of a roadmap as can be seen in many other places in this issue system is to actually list the relevant issues rather than just linking to a query? Please could you put back the information that you deleted?

@geek-merlin Thanks for putting in your time to help with this module. I would be very interested in a clear statement from someone knowledgeable (ideally a maintainer) about the relative status of the 1.x and 2.x branches. In particular

• How complete is the 2.x branch and how stable is it?
• Is every fix in 1.x also in 2.x?

@geek-merlin You are doing a great job, thank you for your time. Sorry I should have been more appreciative of your hard work at the same time as making my suggestion. I'm happy with the clarity of the IS now.

I feel this is an important module. About 1 year ago I volunteered to be maintainer for simplenews D8. It was in a similar state to here, backlog of maintainer tasks, issues blocked, some nasty bugs. I discovered it was a tricky and complex module, but it's now in much better shape.

Swiftmailer is the officially recommended transport for simplenews. But right now the two of them don't even work together without swiftmailer patches (I currently put 4 on my sites). So yes for sure I would like to see some active work here.

I can help a bit, but I wouldn't like to promise too much in addition to the commitments I made already. If you want a second opinion on a tricky issue, or you have created an important patch and need a reviewer I can do that. I could perhaps spend a few hours bimonthly committing patches if the existing maintainers were willing to give me commit access.

1.x uses an unsupported library (which even might have sec issues) so should be unpublished asap.

That's an important point. However 2.x is used by 49 sites and 1.x by 33,000. There might be critical bugs when this module is used with the newer library. I propose that the next step is to create a 2.x-beta1 release - without even committing any more patches that might introduce new problems. At the same time we can stop accepting any patches to 1.x and adjust all the issues to version 2.x. We can commit some existing RTBC patches (especially ones that appear simple, safe and tested by many followers) to 2.x ready for 2.x-beta2. After a few weeks we can change the recommended release to be 2.x. Then a few weeks later we can stop supporting 1.x.

Some of the RTBC issues are not back-compatible, for example #2843327: Load CSS from a theme with CSS inlining which alters a constructor so would break a derived class.

Perhaps we should make the first release to be 2.x-alpha1? Then we can make a beta once all the non-BC issues are committed.

So @geek-merlin shall we do it?? Do you want to ask if we can be maintainers? We can at least try to clear the RTBC issues and move over to 2.x.

Either way, let's make those issues NW.

Well maybe. Good reference to that issue. However we are making a major version change so we don't have to be BC - especially before there is a beta release. I'm worried that if we set a lot of issues to NW then nobody posts new patches we made a backwards step for all the users of this module.

Yes, i'd really like if you add yourself to...

Done

I updated the project so that 8.2.x is the default branch and has automated testing. There is one test failing https://www.drupal.org/node/1163884/qa which looks somewhat similar to the patch in #3093209: Convert simpletest to PHPUnit test.

I will look at #3093209: Convert simpletest to PHPUnit test and #3096960: Drupal 9 deprecated code report for committing as these seem important. I have assigned myself.

I think it's best if I don't commit patches I authored so @geek-merlin please could you consider #3057200: Duplicate error message, #2843327: Load CSS from a theme with CSS inlining, #2812941: Make URLs in links and images absolute?

We should probably wait to create a 2.x alpha release until the tests are passing.

OK I fixed the tests and created an alpha release.

Yes that's a very interesting issue. However it doesn't have a patch and I guess it would be quite a bit of work and destabilisation. Unless someone is offering to do it (I'm not) or to pay for someone to do it then I guess this would have to be left until "next time" 3.x.

Split out #3122389: Bugs with format conversion, new issues #2713651: Add supporting of the Drupal Files as attachments and #3000553: Provide a Drush command for sending out spooled emails

I highlighted some features where we are not sure about for the core swiftmailer module, but could put in a new project "Swiftmailer extra".

Drupal 9 will be released on June 3, 4 days time, on Wednesday. On that date I plan to commit #3126935: Improvements to plaintext conversion then make a Beta release. Any review comments very welcome before then.

OK we have a beta!

Excellent: 1200 users of 2.x beta and no serious bug reports. I have set it as the recommended release. We can wait a few more weeks then mark 1.x as unsupported.

Added a ref to #2223967: Do not decode a contact message twice - core bug that is a security problem here, and presumably a stable blocker.

Would be great if someone could review please.

2.x branch seems to be working well with no major issues reported. I plan to mark 1.x as unsupported. Anyone see any problem with doing that?

OK 8.x.1.x has gone. Stable release still blocked on a reviewer for #2223967: Do not decode a contact message twice

This issue has almost done everything needed. I cleared out the old IS and left a very simple summary.

Great news that #2223967: Do not decode a contact message twice is fixed. We can now create a stable release, with core version requirement set to ensure that the core fix is included. I've updated the IS to describe the remaining steps.

I don't see that #3174600: Allow PHP config sendmail_path to be the default is related to a stable release. It can come just as well before or after. 2.x already has a beta, so we already have to remain back-compatible.

8.x-2.0 (or 2.0.0)

It's too late to call it 2.0.0 unfortunately - the 8.x-2.x branch exists and so the name patterns are already set.

Thanks @Berdir. In my view, this module isn't stable unless you use the appropriate core version. Otherwise anonymous users can send arbitrary emails ignoring the configured text format.

Therefore the stable release should require the appropriate core version. This ensures that sites using the stable version really are secure. Why do you feel that we are "breaking 8.8 support"? I had imagined that users of 8.8 could simply stay on the current beta version. I would expect that composer would automatically provide this solution if the composer.json file requires D8.8 specifically.

Good news - #2223967: Do not decode a contact message twice is in 8.9.11, 9.0.10 and 9.1.0. So next step is for someone to create a patch that updates the info file core_version_requirement.

Thanks for looking at this issue.

The desired behaviour in for minimum core versions 8.9.11, 9.0.10 - that's when the patches were introduced. Or is the third level version not supported?

1) drupal:system (>= 8.7) can be removed as dependency to the module, correct?

I agree this is now redundant.

2) php: 7.0 can be removed from the Swiftmailer.info.yml file altogether, correct? I did not think specific php versions were called in info.yml files, but I could very well be wrong.

I agree. PHP 7.0.8 is the lowest that is supported by Drupal now so this is redundant.

Thanks Chris and Berdir. I have committed the other issue. I'll let the testbot check the new build then create stable. Hurrah success 2.5 years after this issue was opened.