Support » Plugin: BBQ: Block Bad Queries » Release tags

  • Resolved benjaminniess



    Would it be possible in the future to publish a new tag every time you release a new version of the plugin?

    It’s really important for other developers to be able to compare changes from a version to another and in my current case, I’m using composer to build a projet and it can’t work without tags.

    I’m happy to help if you need anything.

Viewing 13 replies - 1 through 13 (of 13 total)
  • Plugin Author Jeff Starr


    Thanks for the feedback. Is it possible to compare the previous version directly with the current version? Seems like it would be something simple to do..

    Hi @specialk,

    Thanks for your quick reply. Actually in the case you mentioned yes it is but let’s say that for some reason you need to compare version 1.0.4 and 1.0.7 and your current version number is 1.0.9, then you can’t.

    It’s common to keep the history of your plugins versions like WordPress does with the core

    And like most of the plugin authors do with their plugins :

    As I mentioned in my previous comment, it’s also important for people like us who use to work with composer which requires a specific plugin version number.

    Thanks mate!

    Plugin Author Jeff Starr


    “..let’s say that for some reason you need to compare version 1.0.4 and 1.0.7 and your current version number is 1.0.9, then you can’t.”

    Yes you can. Pretty sure that’s all possible via the source log:

    There you can grab any versions you want to look at. All plugins hosted here at use SVN, which makes it easy to grab any previous versions and compare however is desired.

    Hello, the matter is not really to view the log history, but rather to follow the WordPress Plugin best practices by adding every releases in tags folder. By this way, we can use composer to manage dependencies and set any version of the plugin we want.

    Hope you’ll consider your position on this issue

    Hello @specialk,

    I totally agree with @benjaminniess and @mista-flo, what finally matters here it’s to get your plugin as composer dependency :

    Let’s have a look at some plugins :
    – Jetpack :
    A lot of releases !
    – BBQ :
    Yours, has only one πŸ™

    Almost all plugins are doing it, the core is doing it, themes begin to do it, so why not either you ?

    To finish, I would say that it’s like a must-have feature as a developper, so please consider it !
    Thank you πŸ˜‰

    Plugin Author Jeff Starr


    Perhaps, but I have some questions before changing my workflow; perhaps you will be so kind as to help me understand the following:

    1) Can you provide some documentation that says “adding every releases in tags folder” is “WordPress Plugin best practices”?

    2) Is it not possible to install an older version of any plugin using the source/release log? (which provides complete copies of all previous versions)

    3) It seems redundant to add an identical copy of every version of the plugin in a different folder, doesn’t it? (a bit rhetorical, but would like to hear your thoughts)

    Thanks for helping me to understand your perspective on this. It’s interesting, if nothing else.

    Plugin Author Jeff Starr


    @maximeculea thanks for the feedback.

    “Almost all plugins are doing it”

    Can you back up that statement with any real stats?

    “so why not either you ?”

    Because there is no real need for it.

    “it’s like a must-have feature as a developper”

    Lol no it’s not. Plugins continue to work fine even without redundant copies in the tags folder.

    Plugin Author Jeff Starr


    That said, I do hear what you people are saying, that it would be a useful feature to have, so I will see about adding a redundant copy of each plugin version to the tags folder. It’s really no skin off my back. Thanks all for the insightful feedback, much appreciated.

    • This reply was modified 3 years, 1 month ago by Jeff Starr.

    Yes it seems redundant but it’s usefull. Check the FAQ about best practices with tags : and that is more explicit.

    By the way, maybe it would be a good practice too to update your tag names, avoid dates and use sem version system :, by doing this, it will be easier to track major updates, for example, when you have a release taged 1.0.0 and a second release 2.0.0, I could know that there is a breaking change in this release that could break my website.

    Thank you for taking time to answer to our requests, hope you will be aware now πŸ™‚

    • This reply was modified 3 years, 1 month ago by Florian TIAR.
    Plugin Author Jeff Starr


    Thanks! Will reference this thread when I tag the next version. Not sure about changing the version number, but will consider it.

    Thanks for your involvement on this usefull plugin πŸ™‚

    Thank you :thumbsup:

    Cheers mate!

    The problem if you decide to change the version number for the semantic way, it that your users will not see your update because WordPress compares the version numbers and 2.0 is wayyy smaller than 20161114 but you should consider it for your next plugin πŸ™‚

Viewing 13 replies - 1 through 13 (of 13 total)
  • The topic ‘Release tags’ is closed to new replies.