Deletion of files pending approval without notification?

I uploaded a new file a few days ago, but before it got approved I recently completed and uploaded the next version.
I usually check my plugin pages a few times a day (check for comments etc.), and today I noticed the previous file that was pending approval is gone.

It feels odd to not even get a pm about a file-deletion...
So basically I'm wondering if this (read title) is normal?

In the case of this plugin and the deleted file it is isn't that big of a deal, but sometimes the newest version isn't the version every user prefers! Sometimes they prefer an older version of a plugin: maybe it has a different config setup, has better compatibility with some other plugin, or the newer version only adds features that they don't really need.

If I had seen such potential here I would have deleted the newest version, uploaded the previous version again, waited for it to be approved, then re-upload the latest version again after that...

So I advocate some communication or at least a notification prior to deletion, or a warning if uploading a new file while another file is still pending approval.

But most of all I'm just a bit surprised at the moment and want some clarification to dispel my confusion.

 

AnorZaken If staff have 2 files waiting to be approved of the same plugin, they will only keep the latest file. They wouldn't waste time validating 2 files as chances are very low that people will want older files. And they can't just approve a file without verifying it.

It's mainly to not waste time with it.

 

Unfortunately, no, when we delete a file there is no automated PM sent to the person who had the file deleted. Nor will we take on PMing each author every time, it is simply too time consuming to manually do so.

If you upload a newer version of a file and an older version is still pending approval, we ask that you delete it yourself. Leaving old files in the queue drastically increases wait times for file approvals - so now instead of having the latest version of your plugin approved (which was marked as compatible with the exactly the same CraftBukkit versions as the unapproved deleted file) in a timely manner, you would have to wait that much longer for your latest, greatest file approved. Today I deleted approximately 75 files for projects leaving the latest file awaiting approval. If we look at each file taking 30 minutes to be approved we saved over 37 hours working approving files that will very rarely be downloaded, or in many cases, not downloaded at all. That's the equivalent of someone working full time for an entire week approving outdated files. It should be pretty clear why our team of volunteers should not be expected to spend their time so unwisely.

You can always expect us to delete previous unapproved files if a newer file exists, as we see no reason to approve a file that will get minimal downloads. If your file is marked for CraftBukkit 1.6.4 and another file marked for CraftBukkit 1.7.10, we would not delete the previous file - but that wasn't the case with your file. You had an incremental update to an existing plugin with no indication that a user would want to download the previous file. Looking at your changelog, you fixed a few bugs in your Alpha 0.0.6, and added configuration and permissions in your Alpha 0.0.7 - which would also include all fixes you had in Alpha 0.0.6.

changelog (open) changelog (close)

v0.0.7 - [permissions (pre-alpha)]

Added permissions!
- Each detector has a 'craft' and a 'use' permission.
- "oredetectors.detector.*.craft" allows crafting of all detectors.
- "oredetectors.detector.*.use" allows usage of all detectors.
- Detectors are still hard-coded, and permission names are:
...iron, redstone, gold, lapis, diamond, emerald.
...for example: "oredetectors.detector.gold.craft"
...(when detectors become fully configurable permission names will be too.)
- If a user lacks permission to use a detector a customizable message will be displayed.
...message customizable in lang.ingame.yml (rename/copy lang.ingame.template.yml)
...(instead of a boring "no permission"-message the default aims for more immersion.)
Added some new config values:
- "permissiondefault.Craft" the PermissionDefault for detector crafting.
- "permissiondefault.Use" the PermissionDefault for detector usage.
...valid values are "true", "false", "op", "!op" (...and a few aliases of those).
...note that these are currently applied to each detector + the asterisk permissions!
...(will have a per-detector setting eventually.)
- "advanced.detectors.MinAsyncTicks" - minimum tick difference between search -> blip.
...I don't recommend touching this unless you look at the source and understand what it does!
- "advanced.detectors.BlipScale" - scales the relation between score and blip level.
...(will probably become a per-detector setting eventually.)
- "color.NoUseMsg" - color for the no-permission-to-use-detector message.
Added a few new variables to the language files...
Some internal code changes in preparation for coming features...
v0.0.6 - [adaptive scheduling (pre-alpha)]

Added partial language support (names of detectors not configurable yet).
Added mcStats.
Added adaptive async block-search scheduling delays.
- Measures required time for async tasks and dynamically adjusts scheduler delays.
- Result: minimal delay between computation and display of the ore-score.
- Async task time is debuggable with new config setting "debug.AsyncTicks"
Fixed bed-blocks missing from list of interactive blocks (non-toggle-right-click).
Fixed a LOT of item-updates & detector toggling!!
- Activating a second OD when a previous OD is still active now correctly deactivates the previous OD-item and activates the new OD.
- Changing world now deactivates the OD (if any OD is active).
- Dying now deactivates the OD (if any OD is active).
- Quitting now correctly deactivates the OD-item (if any OD is active).
- Entering a bed now deactivates the OD (if any OD is active).
- Dropping an active OD-item on the ground now deactivates the dropped item.
- Disabling the plugin now deactivates all OD (e.g. server shutdown / reload).
- Activation and deactivation now works correctly with multiple stacks of the same OD-item.
- Fast spamming of activation & deactivation should work correctly now.

While I agree its unfortunate that the system does not allow automated emails upon a file being deleted, if you want to avoid this in the future wait until your first file is approved before uploading subsequent files.

 

Thanks for the replies!

I suspected as much, I just wanted to know from a reliable source!
(Silent deletion of files feels a bit uncomfortable when you're not completely sure why they happen.)

I support the decisions you made. May I suggest adding this information to someplace official? Maybe the plugin approval guidelines? (Not sure where would be best...)

 

Couldn't you just ask xenForo or your web host or something to implement this? There are plugins for xenForo that do this, im sure of it

 

Ask Curse