FYI, you CAN replicate this right now by adding a script trigger and just have the value of the script be "true" (no quotes). That should trigger for every status and send the emails. Not as convenient, but will meet your requirements before I can get around to implementing this.

I'll backup and say that I was initially confused as to how to use this plugin. It was unclear that you needed to add triggers (which are hidden under the advanced settings pane), to give the plugin any functionality at all.

In my case, I want an email to go to whomever pushed code that caused a build, no matter the result. What I was hoping was that I could use the $GIT_COMMITER envvar in the recipient list (this didn't work with the standard email notification option). Now that I know the workaround you suggested, I'm less concerned about seeing this feature implemented.

Thanks for the update, I'll still see about either given a warning or implementing something.

Created an Always trigger that will always send an email regardless of the status of the build. This trigger will be added by default when no triggers are defined yet.

Code changed in jenkins
User: Alex Earl
Path:
src/main/resources/hudson/plugins/emailext/ExtendedEmailPublisher/config.groovy
http://jenkins-ci.org/commit/email-ext-plugin/227d9b08bc85d5a4fa7c689c9acb4dddf2c44a75
Log:
Fix JENKINS-20013

Added an Always trigger that is setup in the plugin by default. This
trigger will ALWAYS trigger an email to recipients, requestor and
culprits.

Added Always trigger that is added to the list of triggers by default.

Alex: Why change the previous (2.32 or so) behavior to send upon failure (or unstable and worse?) by default? While we have quite a few projects we want to always be notified (success + failure), IMO the default should remain consistent to regular mailer, and not send for stable builds.

Daniel: There were several people who assumed that if there were no triggers defined an email would ALWAYS be sent. I agreed with this as people were confused why they were getting no emails at all, they didn't know they had to setup a trigger to get emails for EVERYTHING.

Alex: That assumption does make some sense. I wondered about triggers completely being missing by default compared to earlier versions of the plugin.

However, I don't get where this leads to adding an 'Always' trigger by default. If it were 'Unstable' or 'Failure', it'd be just as obvious what the behavior is (and users still can customize the triggers to fit their needs, like removing the default trigger and adding the 'Always' trigger) – but it'd match what users might expect is the default coming from built-in Mailer. That's what I was referring to.

Please re-consider this particular choice of the default list of email triggers. I'm sure it'll lead to a lot of unintended 'spam' from carelessly set up instances – Failures, you can argue are important, but successful build notifications? (FWIW it might actually make sense to make the default list of triggers added to new publisher instances configurable globally, similar to default email contents and content type)

Daniel: I'll consider it again before the next release. Even if the list of triggers were configurable, people wouldn't necessarily look there to set it up. I think the best option might be to revert to the older method of adding a failure trigger by default as you suggest.