GH Actions need to ensure libyaml-dev is installed if necessary.
This does not affect the Gem, but will affect development/maintenance.

Also I think it would be useful to include #1534. This is not a regression, but is an issue that can cause random errors.

Gemfile should probably also be synced with master. I don't think strscan is needed.

@sebbASF would you consider these essential for a 2.8.1 release? Eventually we can cherry pick anything to a later 2.8.* right?

Synching Gemfile makes it easier to test, but is not essential.

👍🏻 I don't see any CI results for the 2-8-stable branch (or I'm overlooking...) - so that seems an important thing to fix right after 2.8.1.

That's because test.yml only runs for changes to master.

But surely it's important to run the checks on 2.8 as well?

I've added a PR to show that the build does currently work if test.yml is updated

Saw the PR 🙏🏻 Important indeed.

This is great @eval

Please release #1489 is killing me when testing a new rails project setup script. Thank you!

The change to remove the address_list, which was addressed in rails/rails#46643, is also incompatible with Rails versions before 7.1.

would love to see #1511 released soon if possible!

I'm struggling to figure out why the gem was not yanked immediately. It is clearly broken and shipping a fix is taking a long time (which is fine, this is OS and we are all doing our best). So why not yank the gem?

So why not yank the gem?

It's indeed something I suggested to Mikel via e-mail. As the above mentioned issues are apparently not exhaustive to cut a backwards compatible release, I hope one of the gem owners @mikel and @jeremy (?) could yank 2.8.0.

@eval i can set aside some time to help with testing & whatever else is needed to do a release. lmk if that would be useful.

Please release or yank... rails-lambda/lamby-cookiecutter#25

I am an OS maintainer too and I have a lot of empathy for those that run projects. This issue is likely wrecking havoc on folks starting new Rails application across many different spectrums, including my own community. Why the v2.8.0 gem was not yanked immediately is something I do not understand. It's like leaving a bad deploy out there and working the fix under duress vs. doing a revert and thoughtful fix.

Is there any reason to not limit the release of 2.8.1 to just fixing the file permission issue? It seems to be the most impactful. I'm not familiar with the release process, but hopefully it is not so onerous that we must wait for a larger batch to release. Alternatively, yes, yanking the gem would be appreciated.

Is there any reason to not limit the release of 2.8.1 to just fixing the file permission issue?

This issue lists several non-backwards compatible problems with v2.8.0 that would cause errors only at 'send-time'.
The permission-issue OTOH causes build-/boot-time errors which prevents people from upgrading to v2.8.0. You could say that's a positive thing.

yank it then ffs.

We have a minor issue in the system now because of incorrect file permissions Is there any schedule for 2.8.1 release, please? Do we need to wait or should we rollback to 2.7.1?

I think we are well past the point of yanking right? Can the team tag v2.8.2 using the same v2.8.1 tag/sha and push a gem with the right file permissions?

If possible, a htofix with corrected permissions would be really appreciated. Like many others, I ran into this too. A small fix with just the corrected permissions would make my life a lot easier.

As a fellow open source maintainer, I understand that life gets in the way and it can take time to issue fixes, of course. I get that you may not have had the time to release anything new.

Suggestion. Checkout the v2.8.0 tag, change the version to v2.8.0.1, publish a new gem, ensure perms are good.

It seems like @mikel is busy with other things right now, which is unfortunate for the ones being bitten by the file permissions issue, but 100% ok. We can still work around this by locking mail to 2.7.1.

According to RubyGems, @jeremy has the permissions to cut a new release, too. So @jeremy, is it possible that you publish a new minor release of this gem with fixed file permissions? You can just check out the 2.8.0 tag, bump the version and publish. This would help me and probably others a great deal.

I don't know how the faulty file permissions got into the current release in the first place, but looking at the Rakefile, there's nothing wrong. It seems to be an issue on the machine used by the original publisher of the 2.8.0 version.

Original file permissions issue is here:
#1489

Pushed a 2.8.0.1.rc1 with file perms fixed and no other code changes. @ralph and others, would you please verify?

@jeremy Thank you very much for you effort. I can confirm that 2.8.0.1.rc1 has the correct file permissions and works flawlessly in our docker based environment.

For full reference, here are the file permissions for 2.8.0:

root@88f81242206b:/app# ls -ls /usr/local/bundle/gems/mail-2.8.0/lib/mail
total 244
 4 -rw-r--r-- 1 root root  3481 Jan  9 08:19 attachments_list.rb
12 -rw-r--r-- 1 root root  9545 Jan  9 08:19 body.rb
 4 -rw-r--r-- 1 root root  1940 Jan  9 08:19 check_delivery_params.rb
 4 -rw-r--r-- 1 root root  1781 Jan  9 08:19 configuration.rb
 4 -rw-r--r-- 1 root root  2472 Jan  9 08:19 constants.rb
 4 drwxr-xr-x 2 root root  4096 Jan  9 08:19 elements
 4 -rw-r----- 1 root root   960 Jan  9 08:19 elements.rb
 4 drwxr-xr-x 2 root root  4096 Jan  9 08:19 encodings
12 -rw-r--r-- 1 root root  9792 Jan  9 08:19 encodings.rb
 4 -rw-r--r-- 1 root root   573 Jan  9 08:19 envelope.rb
12 -rw-r--r-- 1 root root  8885 Jan  9 08:19 field.rb
 4 -rw-r--r-- 1 root root  2077 Jan  9 08:19 field_list.rb
 4 drwxr-xr-x 2 root root  4096 Jan  9 08:19 fields
 4 -rw-r----- 1 root root  2244 Jan  9 08:19 fields.rb
 8 -rw-r--r-- 1 root root  7528 Jan  9 08:19 header.rb
 4 -rw-r----- 1 root root  3874 Jan  9 08:19 indifferent_hash.rb
12 -rw-r--r-- 1 root root  8346 Jan  9 08:19 mail.rb
 4 drwxr-xr-x 2 root root  4096 Jan  9 08:19 matchers
68 -rw-r--r-- 1 root root 67382 Jan  9 08:19 message.rb
 4 drwxr-xr-x 2 root root  4096 Jan  9 08:19 multibyte
 4 -rw-r--r-- 1 root root  3563 Jan  9 08:19 multibyte.rb
 4 drwxr-xr-x 4 root root  4096 Jan  9 08:19 network
 4 -rw-r--r-- 1 root root   836 Jan  9 08:19 network.rb
 4 -rw-r--r-- 1 root root   446 Jan  9 08:19 parser_tools.rb
 4 drwxr-xr-x 2 root root  4096 Jan  9 08:19 parsers
 4 -rw-r--r-- 1 root root   522 Jan  9 08:19 parsers.rb
 4 -rw-r--r-- 1 root root  3124 Jan  9 08:19 part.rb
 4 -rw-r--r-- 1 root root  3374 Jan  9 08:19 parts_list.rb
 4 -rw-r--r-- 1 root root  1410 Jan  9 08:19 smtp_envelope.rb
16 -rw-r--r-- 1 root root 16176 Jan  9 08:19 utilities.rb
 4 drwxr-xr-x 2 root root  4096 Jan  9 08:19 values
 4 -rw-r--r-- 1 root root   233 Jan  9 08:19 version.rb
 4 -rw-r--r-- 1 root root   655 Jan  9 08:19 yaml.rb

And for 2.8.0.1.rc1:

root@88f81242206b:/app# ls -ls /usr/local/bundle/gems/mail-2.8.0.1.rc1/lib/mail
total 244
 4 -rw-r--r-- 1 root root  3481 Jan 12 19:21 attachments_list.rb
12 -rw-r--r-- 1 root root  9545 Jan 12 19:21 body.rb
 4 -rw-r--r-- 1 root root  1940 Jan 12 19:21 check_delivery_params.rb
 4 -rw-r--r-- 1 root root  1781 Jan 12 19:21 configuration.rb
 4 -rw-r--r-- 1 root root  2472 Jan 12 19:21 constants.rb
 4 drwxr-xr-x 2 root root  4096 Jan 12 19:21 elements
 4 -rw-r--r-- 1 root root   960 Jan 12 19:21 elements.rb
 4 drwxr-xr-x 2 root root  4096 Jan 12 19:21 encodings
12 -rw-r--r-- 1 root root  9792 Jan 12 19:21 encodings.rb
 4 -rw-r--r-- 1 root root   573 Jan 12 19:21 envelope.rb
12 -rw-r--r-- 1 root root  8885 Jan 12 19:21 field.rb
 4 -rw-r--r-- 1 root root  2077 Jan 12 19:21 field_list.rb
 4 drwxr-xr-x 2 root root  4096 Jan 12 19:21 fields
 4 -rw-r--r-- 1 root root  2244 Jan 12 19:21 fields.rb
 8 -rw-r--r-- 1 root root  7528 Jan 12 19:21 header.rb
 4 -rw-r--r-- 1 root root  3874 Jan 12 19:21 indifferent_hash.rb
12 -rw-r--r-- 1 root root  8346 Jan 12 19:21 mail.rb
 4 drwxr-xr-x 2 root root  4096 Jan 12 19:21 matchers
68 -rw-r--r-- 1 root root 67382 Jan 12 19:21 message.rb
 4 drwxr-xr-x 2 root root  4096 Jan 12 19:21 multibyte
 4 -rw-r--r-- 1 root root  3563 Jan 12 19:21 multibyte.rb
 4 drwxr-xr-x 4 root root  4096 Jan 12 19:21 network
 4 -rw-r--r-- 1 root root   836 Jan 12 19:21 network.rb
 4 -rw-r--r-- 1 root root   446 Jan 12 19:21 parser_tools.rb
 4 drwxr-xr-x 2 root root  4096 Jan 12 19:21 parsers
 4 -rw-r--r-- 1 root root   522 Jan 12 19:21 parsers.rb
 4 -rw-r--r-- 1 root root  3124 Jan 12 19:21 part.rb
 4 -rw-r--r-- 1 root root  3374 Jan 12 19:21 parts_list.rb
 4 -rw-r--r-- 1 root root  1410 Jan 12 19:21 smtp_envelope.rb
16 -rw-r--r-- 1 root root 16176 Jan 12 19:21 utilities.rb
 4 drwxr-xr-x 2 root root  4096 Jan 12 19:21 values
 4 -rw-r--r-- 1 root root   237 Jan 12 19:21 version.rb
 4 -rw-r--r-- 1 root root   655 Jan 12 19:21 yaml.rb

Also let me add that I had to think of this a lot. So thank you again for contributing to open source.

Thank you so much, @jeremy! 🙇‍♀️ ❤️ 👏

Thanks for the verification! Pushed 2.8.0.1.

FWIW, it's still broken for us, this time because of #1550, which is what @eval was trying to warn us about as this is arguably a worse break (it isn't discovered at deploy time, it is discovered at send time)

Hej friends, Mikel just released the first 2.8.1 RC that includes fixes for #1434, #1550 and #1538.

Testdrives and feedback appreciated 🙏🏻

@eval this works for us, thank you!

I can also confirm this 2.8.1.rc2 working. (at least for fixing the #1538 rails config issue). Thank you!

@eval I also confirm 2.8.1 RC2 is working well in our side (we basically encountered this issue: #1538).

Thanks you so much!

Thanks all for the feedback on the RC! I tagged v2.8.1 and asked Mikel to cut the release. I'll close this issue when the release is available.

Mikel just released v2.8.1 🎉

Thanks everyone for their input, tests, fixes and patience! 🙏🏻