I'm not sure about this, at the first glance I would add a new plugin with a new name to bypass "plugin disabled" situation, on the other side it would be easy for us to active the plugin again after upgrading to 5.4 or 5.0, also since we know the rough schedule we plan to release 6.0 it should be possible to have some clear data on j5.0 release...

I would name it simply plg_quickicon_eos and also not only use it for new major versions. We know roughly when we are releasing our minors and we know when we are releasing our majors, so I don't see a reason why not to bug people also when they haven't updated to the next minor a month after our scheduled release. We could pull in the data from the update check here as well. That would also mean, that we have to enable that plugin on each update, be it major, minor or patch. A diligent user would never see it, but those who don't update their minors either would get a notice again.

I'm not a fan of just concentrating on the major versions here, because our minors don't get any support the moment the next minor is released, so we should also make sure people do understand that.

A persistent plg_quickicon_eos seems a good idea, we just enable/disable it when a time is come :)

Like when User do update from 4.3 to 4.4 (or new installation of 4.4) then force this plugin to be published.
Same would be when updating to last 5.x in 5 series.

Also could work between minor versions, as Hannes wrote.

So it seems up to now all (including me) prefer a persistent plg_quickicon_eos.

I'd like to know @zero-24 's opinion as he was the one who made the 3.10 EOS plugin, as far as I remember. Maybe we are missing something and it had a reason to make it version specific?

And I'd pretty much like to have the opinion of the 4.4 release leads, @laoneo and @MacJoom .

For me it would also be ok to have a persistent OEL plugin, which can also be used for PHP EOL or any other EOL message we need to show to the end user.

I'd like to know @zero-24 's opinion as he was the one who made the 3.10 EOS plugin, as far as I remember. Maybe we are missing something and it had a reason to make it version specific?

There is no specific reason. We have done it that way within 2.5 and uninstalled the plugin afterwards. This is what i have implemented here too. But I would still recommend a version specific eos plugin to make sure its actually dedicated and the correct versions / dates are shipped. And the people have a way to implement the required orverrides.

For me it would also be ok to have a persistent OEL plugin, which can also be used for PHP EOL or any other EOL message we need to show to the end user.

I do disagree to combine the plugins, people will ask "how to get rid of this message" and people will tell them to disable the plugin which will result into both messages to be hidden.

I'm not a fan of just concentrating on the major versions here, because our minors don't get any support the moment the next minor is released, so we should also make sure people do understand that.

There is already a message "there is an update ready please update" I dont see why adding more messages should help here.
Within 3.10 -> 4.x there is no automatic update proposed and a migration is needed. This is not the case for 4.0 -> 4.1 as that will be proposed directly.

I would name it simply plg_quickicon_eos and also not only use it for new major versions. We know roughly when we are releasing our minors and we know when we are releasing our majors, so I don't see a reason why not to bug people also when they haven't updated to the next minor a month after our scheduled release. We could pull in the data from the update check here as well. That would also mean, that we have to enable that plugin on each update, be it major, minor or patch. A diligent user would never see it, but those who don't update their minors either would get a notice again.

I do strongly disagree with this. Again there is a "update aviable now" message for that cases already.

I don't see a reason why not to bug people

There are reasons and what could better "bug" people than an update email and message as soon as you enter the backend? ;)

I'm not sure about this, at the first glance I would add a new plugin with a new name to bypass "plugin disabled" situation, on the other side it would be easy for us to active the plugin again after upgrading to 5.4 or 5.0, also since we know the rough schedule we plan to release 6.0 it should be possible to have some clear data on j5.0 release...

That would be my suggestion too. Ship with the latest minor an dedicated plugin, publish the strings as blog or docs page, its not disabled by default and uninstall the previus plugin via the next major update.

agree with @zero-24

From a maintenance perspective it is a nightmare to add every 1 1/2 year a new plugin and then at the same time remove it in the next major.

Ok, I think we have a consent. We create a plugin with will be permanently part of Joomla and handles the eof life cycle. Would it make sense that this plugin pulls the information from the update server? Every month or so? Since it's only a quick icon it's only loaded in the backend.

As alternative when the Joomla Update Notification plugin is changed to use the scheduler it maybe make sense that this plugin pulls also the eos information...

btw. I also think we are bugging people enough with update warnings.

I guess this can be closed now