Stable tag naming scheme for automation

[Toucan-Sam]

It would be amazing to publish all the Essentials plugins with an additional tag and standardized naming to allow for automated plugin pulls.

Eg https://github.com/EssentialsX/Essentials/releases/download/stable/EssentialsX-stable.jar

Given all the log4j stuff recently (not directly Essentials), having a way to automatically update plugins is super handy. Manual updating is always an option but a bit tedious.

Alternatively, publishing the Essentials X plugins via spigot.org's SPIGET API would be an option, but given the project is on Github, probably easiest to just publish another release.

[mdcfe]

To quote my response to #4719:

No. Automatically updating server software and plugins is a recipe for disaster, and we do not intend to support any solutions to that end.

Server owner's should be responsible for checking for software updates and changelogs for breaking chabges, and ensuring that updates are tested on a non-production setup before being applied to a server. We're not going to facilitate anything that lets people skip this responsibility.

[Toucan-Sam]

Sorry. Threads are a thing. Responded here. Apologies if you already got an email for that.

[Toucan-Sam]

Apologies. I did do a search, but didn't find the references to autoplug.

I agree with you wholeheartedly that server owners are responsible for their services and also acknowledge that it is 100% your choice to do or not do something. No bad blood, I promise. If discussion is not open, feel free to close the this.

In my case, I run a pair of small servers for friends and family. The container it runs in auto-updates because I don't have time to frequently check for the latest updates of all the plugins. All 10 people who use them can deal with an outage and I will manually roll back if there is a problem.

The work I am employed to do definitely requires more testing and validation and passing through multiple environments. And it is entirely my responsibility to make sure those steps happen. If I push something to prod without validating, that is my fault.

I would also be happy using a latest tag that mirrored the stable branch if the terminology is a problem. Honestly, I would even be comfortable using latest against a dev branch, but I'd personally prefer it follow stable.

If for nothing else, this would allow me to build a non-production server quickly and repeatedly to be able to validate if it works or not. After that, I could choose to push those changes to the "production" branches I'm responsible for. Both of my servers are containerized for deployability. Except for a handful of plugins like this one.

IMHO, stable is only stable to YOU. It is fundamentally not this team's responsibility to validate stable against every possible configuration. If you just don't want to deal with the questions that process could raise then that seems like a legitimate burden to avoid. Though I think it would be small.

However, you already use automated processes to build and publish your work. You also publish to both ci.ender.zone and Github. I assume at some point, you have determined that your work is ready to be published. Why not make it easier for people to get at it and help people keep up-to-date?

Again, I'll repeat that it's 100% up to you guys to decide how to manage your project. I'm just advocating for this particular feature. Either way, thanks for responding! <3

[JRoy]

The GitHub releases API will give you a list of releases which are deemed to be stable. Still do not automatically update.

[Toucan-Sam]

It does, but the names change with each individual version. Which is not an unreasonable thing to do.

I would also welcome an auto release tag that tracks stable so it's clear that it is meant for only non-production use.

[mdcfe]

We will not be adding any tags or alternate names for any builds we publish. The various services we host downloads on already give you enough information to do what you want.