[wp-meta] [Making WordPress.org] #5352: Plugin Security - Add email confirmation prior to releases being processed
Making WordPress.org
noreply at wordpress.org
Mon Aug 10 02:10:49 UTC 2020
#5352: Plugin Security - Add email confirmation prior to releases being processed
------------------------------+---------------------
Reporter: dd32 | Owner: (none)
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: Plugin Directory | Resolution:
Keywords: |
------------------------------+---------------------
Comment (by dd32):
Replying to [comment:14 Ipstenu]:
> I'm sitting on the fence about disallowing 'trunk' as a stable version.
I (personally) laud it. I'm also aware that people like to dev how they
like to dev.
My only want for it, is that it makes the implementation of this a LOT
simpler and has other benefits.
When I say it makes it a lot simpler, I really mean it's a lot simpler (to
the point, that I actually consider it a ''requirement''), the edge cases
that need to be handled are significantly decreased and errors on
WordPress.org would be significantly reduced.
If it is a massive issue, then we could consider a "You bumped the version
in trunk, let's tag a release!" email that has a button (like I mentioned
above) that both a) confirms the release action and b) tags everything for
them.
> > Thankfully only 15% of plugins with >= 100k active installs use trunk,
but that's still not a small number.
>
> We have ~57k active plugins at the moment. How many of those (raw
numbers) use trunk?
Raw numbers. (This differs from the 15% number quoted above, as I used
>100k instead of >=100k)
||Active Installs||Plugins||Using Tags|| ||Using Trunk|| ||
||>=100k||404||329||81%||79||19%||
||>=10k||2,399||1,671||70%||728||30%||
||>=1k||8,845 ||5,509||62%||3,336||33%||
||All||56,878||27,097||48%||29,781||52%||
That shows much closer to what I thought - the larger a plugin the more
likely they are to use tags.
> We can also say "disable auto updates for plugins using trunk as stable"
though I don't know if the API (as is) is robust enough to handle that.
It's something we should consider.
The API is, but it won't be a good user-experience as core implementation
isn't robust enough for it.
--
Ticket URL: <https://meta.trac.wordpress.org/ticket/5352#comment:17>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org
More information about the wp-meta
mailing list