Auto Updaters

Discussion in 'Bukkit Discussion' started by Zettelkasten, Jul 16, 2014.

Thread Status:
Not open for further replies.
  1. Offline

    Zettelkasten

    Hello, I am wondering what you (plugin developers and server owners) think about auto updaters: Are auto updaters annoying because they spam chat / console? Do you actually use them, ignore them or disable them? And how often do you want a plugin developer to push out releases or should they do more features per release (I guess bug-fixes are different)?
    I am looking for answers this to find out the best default value for auto-updating in the configuration of my plugins (disabled, console only, inform operators). Thanks for your answers!
     
  2. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı

    I only perform update checking in one of my plugins. It just checks for a new release and informs those with the appropriate permissions of this update. It doesn't download it; that's up to the admin to acquire themselves. The check is enabled by default, but does not happen on first startup (when config files are copied and such) and instead warns you that future startups will automatically check and inform about updates unless disabled. I feel that this way, I by default let you know useful information, but let you decide whether you want it checked and when you update.

    For my other plugins I don't bother, and figure users can update when they feel like it (or in the case of TagAPI, when it breaks).
     
    Zettelkasten likes this.
  3. Offline

    MCMatters

    Could you make a resource of how to update check?
     
  4. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı

  5. Offline

    Bobcat00

    The problem is that there are plugins which automatically download the new version. Because of that, I have globally disabled the update checks, which makes the entire feature useless to me.

    I suggested that they provide a global way to allow notification only (no downloads), but they refused to do it.

    Bottom line: The updater in its present form is useless.

    Avoid "feature creep". Stick to a coherent set of capabilities, and don't add a bunch of extraneous stuff. As an example of what NOT to do, see GriefPrevention. They took a great plugin and added so much crap to it, they can't get it to work right and it's a configuration disaster for server owners.
     
  6. Offline

    xbenas

    I despise any kind of plugin which checks for updates without my permission, aka it's made to check in the default plugin config. Not only does that violate my freedoms, it creates a bunch of folders I don't know and is prone to break plugins.
    AntiCheat once updated when I was running an older version of CB and started spitting errors in the console and started lagging.
    Same goes for metrics, but atleast those don't break the server.

    Bobcat00 RIP GriefPrevention. Any worthy replacements for that?
     
  7. Offline

    Bobcat00

    xbenas Do what I did:

    plugins/Updater/config.yml: disable: true

    plugins/PluginMetrics/config.yml: opt-out: true
     
  8. Offline

    Zettelkasten

    Thanks for all your replies!

    mbaxter Bobcat00 I would never download anything to a server, the only thing I want to do is inform the operators of there is an update available.
    The configuration of GriefPrevention is indeed horrible. I sometimes find myself wanting to make stuff super-configurable, but then I notice, that properly nobody will bother changing it anyway. For my 6-person server, I don't bother configuring some plugins at all.

    xbenas Yes, noticed that too. A configuration option like "disableDownloads" would fix that, maybe.

    Having that said, I wonder why plugin developers should include them at all: If the plugin breaks, the server owners know they need to update it. If they want a new feature, they update it. The only purpose is when there are severe issues that are note easily visible ... And if it is important to the server that all plugins are always up-to-date, they can subscribe to updates on Bukkit Dev.
     
  9. Offline

    xbenas

    The problem is not all plugins depend on the said updater, some make a system of their own for their plugin so you are stuck reading every plugin's config file anyway.

    Also, like I asked before, any good GriefPrevention replacements? I am wiping my server clean so I don't need any database migrations. Residence seems outdated and other protection plugins lack GP's features and just feel alien to me. halp
     
  10. After all i tend to dislike all the auto-metrics/updating stuff, because they are opt-out based and also can be harmful potentially, further many plugins have different configurations and ways to handle it (as useful as those are for either side). A server wide set of flags provided by Bukkit could be good, to be able to opt out from any downloading or metrics features (Bukkit enforcing sanity), Bukkit could even add a SecurityManager per plugin :p.

    Contra:
    Plugin-dependencies blowing up with auto updating, in some cases your config could explode with the very plugin that updated.

    Pro:
    Pimping the download count, especially with re-downloading the same versions, but more important: keeping people protected (for the case of protection plugins).

    Conclusion:
    For me i would at most like to add a notification about outdated or dangerous versions, and maybe the possibility to download new versions by a command, of course all dectivatable by config. It would much help to have the clickables/hoverables chat features in the Bukkit API for such purposes - then we could just parse some compatibility notice inside the jar and let the user decide if to "delete all past data with this update", "don't install the new version, but apply config changes to undo a crash exploit" or whatever the options could be then. There are already different ways to handle auto updating, so far i have seen "always update", "only within this major version" and "just notify". I will probably add "notify and let the user decide" and proabably probably "... + parse compatibility notice and let the user decide what to do based on that".
     
    Zettelkasten likes this.
  11. Offline

    Bobcat00

    I'm hoping that by the time Mojang lets people change names, that there will be a better version of GriefPrevention 7.8. I guess it will still have the bloated configuration. They even have a rule for placing flowers in flower pots, and you have to define that for every world you have.
    I used ProtectionStones in the past, but I think GriefPrevention is better. GriefPrevention leads the player into proper usage. It also expires old claims.
     
  12. Bobcat00 You mean "WorldGuard Some other plugin" instead of "NoCheatPlus"? NCP is not critical to update towards UUIDs, though it will eventually happen - i still have to check what it will be with offline mode (testing-) servers, to ensure players have differing uuids there (otherwise some things can not be tested offline - not the end of the world, but somewhat painful for people who can't spend the extra money to have access always or multiple accounts (i do have).).
     
  13. Offline

    Bobcat00

    asofold Sorry, I meant GriefPrevention. I get GP and NCP confused for some reason. Don't know why. NoCheatPlus is working fine.
     
Thread Status:
Not open for further replies.

Share This Page