[Meta] Release version 1.0.0

Essential issues have been rounded up and marked as children.

Up for debate :

• https://www.drupal.org/project/digest/issues/3166231

Too things that have not been made into separate issues but still worry me are :

• CSS in emails.
  • I know that email clients can be difficult to work with for CSS. I wonder if by rendering a block that there will be too much CSS from within a site to deal with. Do we expect that a themer has made an email template with the relevant and needed properties? What about issues for in-lining CSS since some clients (like Gmail) do not play nice with non-inline CSS.
• Sending out empty Digests.
  • How can we make sure digests do not send when there is no content? Using blocks, there would seem to be no sure-fire way to tell if
    a block is empty considering you could be sending out a static block (perhaps the use case there is "hey did you log time?"). Since we don't limit this to views or a specific, like a content type, it seems we may often be sending out blank digests.

Added issue 3168353 for utilising the config entity status.

In reference to #4 empty digests :
The common use case where this occurs is using a view as a block. In this case, views have the a "no results" setting to define what should happen in the case of there being no results. For now, there will be no way to detect an empty digest and avoid sending it altogether. Users should set up something like a fall back for a view to display.

In the future, if this proves to be an awful idea, we can add in an event that allows developers to override the shouldSend or the queuing them. This would allow for a custom check, for instance "is there new content", and stop a digest from sending.

That was problems itself and would likely only work in a rather static / small site seeing as that would presumably apply to all digests or you'd need to reference the name of it (bad practice). But that all comes later.

Two notes

CSS, after using this on a real site, using Swiftmailer and the new CSS inlining features in 2.0 there should be no problem if you use the right tools.

If we want that ability to cancel digests, I'm going to suggest just making a 'send event' that is fired when a digest tries to send. Give it an option 'cancel' and we should be golden.

This issue will contain a patch for updating the readme and such (anything pertaining to early development warnings) Once this is ready for a stable release.

A release candidate has been made : https://www.drupal.org/project/digest/releases/1.0.0-rc1
After a little further testing this should be ready for the big leagues.

Back with a continuation of my thoughts in #6

Stop digests from sending with a hook, event, or we could do a plugin.

This would be a fairly large change and might not be able to be here until v2 unless it's really wanted here. I don't know if this would be replacing the schedule or adding onto it.

Adding onto it:
We allow each digest to specify a list of "conditions" to send out during. These conditions are plugins that allow for us to easily add extra requirements for sending. For instance, I imagine a "New Content" plugin which allows you to choose a time frame, content type to check for, and how many new ones there should be. Then this will not send the digest if there is no new content for it.

Replacing:
This is more of a wild thought, I just wonder if it would then be smart to streamline the schedule into a plugin as well. If so, it'd probably be wise to make this a default on every digest. But theoretically you might want to have a (not quite) digest that sends out as soon as a piece of new content is detected.
With this approach, everything is kept stream lined and some responsibility is lifted from the digest class. It does allow for maybe a more general use case of the digest (somewhat sending out single pieces of content or similar).

The problem with enabling and disabling is that digests are config so that's changing your code base often.

I just wanted to jot down the idea so it would not be forgotten. It'll be made into a separate issue later.
The actual scheduling mechanics of the cron expression wouldn't change in the users eyes.

When it'll send for users is covered here https://www.drupal.org/project/digest/issues/3162691 which will likely be a 1.1 addition. I know there was mention of adding the same to the digest list. Same story there.

I'm going to mark this as NR and if community members or myself (in a little while) change it over to RTBC I'll consider that good enough for the full release.

Applied for security policy, https://www.drupal.org/project/projectapplications/issues/3174609

Hopefully that doesn't take too long, D.O seems to warn against making a full release until we have that. So I will hold back for a moment.

Repo is ready and tagged. The commit just removed the active development warning from the readme.

I am going to include a new feature in the release. Setting back to needs review. But we will need to make a new RC (might be better as a beta though).

Adding a new issue to the related.

Switching back to NW for a while. Some new issues have been brought up. This means that there will need to be a new RC before full launch.

Might look to make a beta in the next few days. Seemed to jump the gun a bit on the RC, but honestly I love finding issues because then I can make this better.

We have gained security coverage! #3174609: [D9] Digest

I have also made a new beta release as the current RC-1 is not a good image of what has now been done to the module. I know there are a few important issues still up as NR but I think it is necessary to get a more current release up for now. Also aware it is somewhat bad progress to regress from RC to beta but hey, what are ya gonna do eh?