Skip to content

UPDATE: Email queued_at field #37

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Dec 4, 2021

Conversation

vkislichenko
Copy link
Contributor

Currently if SendEmailsCommand is used with queuing e-mails from EmailComposer - it might result in sent email duplicates

I've added queued_at field to Email model
It will be populated after EmailComposer::queue() is called
SendEmailsCommand will now check for non queued emails

@marickvantuil marickvantuil merged commit 563c22a into stackkit:master Dec 4, 2021
@marickvantuil
Copy link
Member

Thanks! I am still thinking what version to assign to this and the other change. In my opinion, it's more leaning towards a breaking change because it requires migrations to be run, and I cannot assume people are doing this automatically. So for that reason I am thinking of tagging this as 5.x. Do you agree? Also, if we do tag this 5.x, then it might actually be nicer to always publish migrations instead of loading them with loadMigrationsFrom? So we could remove the config option added in #36?

@vkislichenko
Copy link
Contributor Author

I am still thinking what version to assign to this and the other change. In my opinion, it's more leaning towards a breaking change because it requires migrations to be run, and I cannot assume people are doing this automatically. So for that reason I am thinking of tagging this as 5.x. Do you agree?

yep, seems reasonable
though if possible users still should be notified about breaking changes
maybe with something like this (while I cant find it in doc outputWarnings() is still there)

Also, if we do tag this 5.x, then it might actually be nicer to always publish migrations instead of loading them with loadMigrationsFrom? So we could remove the config option added in #36?

That one I'm not sure, on smaller projects it's actually nice when package deals with migrations internally (when you don't really care what it does - while it does work)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants