You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In light of this, I'd like to propose that we make the use of tags enforceable via the guidelines.
The biggest factor for this is automated rollbacks of a failed automatic update, this also goes for the use of wpackagist for those that use composer, since they honor the plugin directory and their available versions, and remove older versions that are no longer served by the directory.
My thinking is that the guidelines should require the use of tags moving forward, with any new release made (so as not to punish those who have used trunk and haven't made changes since).
I'm not sure if this would be enforceable on a directory level with code or not, since trunk should obviously still be available for those using it as a beta channel, but with the guidelines in place, it would at least be possible to push people to doing it right and some stern words if they don't.
The text was updated successfully, but these errors were encountered:
I'm flagging this 'maybe later' because, as I know you know, I hate making guidelines that aren't easily enforcable.
Now we do check for (and push back on) this in reviews, but that only covers new plugins and old ones closed for reasons.
Before we look into making this a guideline, I would rather we put time in to blocking the use of 'trunk' as a valid tag in SVN. If we can do that, then we don't need a guideline because, neener, it's already blocked.
I'm not sure if this would be enforceable on a directory level with code or not, since trunk should obviously still be available for those using it as a beta channel
Well now that's a fun thing. SHOULD Trunk be available for a beta channel? Why not make people always use tags? Release a tag 1.3.1-rc1 and so on. After all, Core can...
Yeah, totally on board with the difficulty of not-easily enforceable guidelines, just got burnt by the third trunk-only plugin in a week, so it made sense to put my thoughts and ideas to words, no discussion or change without it after all :)
I actually kind of like the idea of not using trunk for betas, and instead having releases that you don't mark as stable tags. That should also work well with any automated deploy systems folks are using, just don't change stable tag when creating your deploy and you've got a pre-release/beta/whatever 🤔
A post was made this year, outlining how tags are preferred over just using trunk for releases (https://make.wordpress.org/plugins/2021/03/16/trunk-vs-tags-which-is-better-tags/).
In light of this, I'd like to propose that we make the use of tags enforceable via the guidelines.
The biggest factor for this is automated rollbacks of a failed automatic update, this also goes for the use of wpackagist for those that use composer, since they honor the plugin directory and their available versions, and remove older versions that are no longer served by the directory.
My thinking is that the guidelines should require the use of tags moving forward, with any new release made (so as not to punish those who have used trunk and haven't made changes since).
I'm not sure if this would be enforceable on a directory level with code or not, since trunk should obviously still be available for those using it as a beta channel, but with the guidelines in place, it would at least be possible to push people to doing it right and some stern words if they don't.
The text was updated successfully, but these errors were encountered: