Support » Plugin: footnotes » 2.5.10 reverts 2.5.9d1 and apologies

  • ResolvedPlugin Author Mark Cheret

    (@markcheret)


    Dear footnotes community,

    thank you for your continued support.
    I’m sorry we shipped a broken version of the plugin earlier today and we reverted to a stable version with the latest update 2.5.10. Please update to this release and keep watch the plugin page for further updates.

    We’re working tirelessly to bring you an amazing experience and are introducing a test automation and coding standards.

    If you want to contribute fixes and enhancements, development is an open process at https://github.com/markcheret/footnotes

    Best wishes
    Mark

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Author Rumperuu

    (@rumperuu)

    As this was a serious issue, I have conducted a full post-mortem. A full technical breakdown of what happened is available on the GitHub repo. Issue for this incident here; this is an abridged general-purpose summary.

    Issue

    As part of refactoring the codebase to comply with the WordPress Coding Standards (the first step in a wider project of migration and workflow automation), the following file and directory renames were made:

    • class/dashboard/class/layout/;
    • class/dashboard/layout.phpclass/layout/abstract-engine.php;
    • class/dashboard/subpage-diagnostics.phpclass/layout/diagnostics.php; and
    • class/dashboard/subpage-main.phpclass/layout/settings.php.

    To account for these relocations, the penultimate line of includes.php was changed from mci_footnotes_require_php_files( dirname( __FILE__ ) . '/class/dashboard' ); to mci_footnotes_require_php_files( dirname( __FILE__ ) . '/class/layout' ); to ensure that the new files were found.

    In the v2.5.9d1 commit to trunk/, the updated includes.php was included (see here), but the class/dashboard/class/layout/ directory rename was not (see here).

    includes.php tried to find files in a non-existent directory, couldn’t, and threw a fatal error.

    What Happened

    1. I did not realise that the steps given in the WP Plugin Handbook for updating the SVN repo. were only for ‘Editing Existing Files’. class/layout/ was present in my local copy of trunk/, but as the new class/layout/ directory was not yet added to tracking (i.e., through svn add), it was not included in the svn stat or the commit, whilst the updated version of includes.php (which pointed to it instead of class/dashboard/) was;
    2. I did not notice this in my test environment because copying the files from my local copy of trunk/ meant that I included my local (but un-committed) copy of class/layout/;
    3. as the codebase standardisation changeset covered 45 files, the commit diff filelist was too long for anyone to notice that the class/layout/ directory was missing;
    4. this would have been noticed as soon as anyone else pulled the remote trunk/ to their local copy and tested it; but
    5. the code in trunk/ was taken by the WP Plugin Directory to be a new release (2.5.9d1):
    • per the WP Plugin Handbook (see here), the Directory parses the ‘Stable Tag’ field in trunk/readme.txt first and, if the value is set to something other than ‘trunk’, will look in tags/⟨stable_tag⟩;
    • again per the Handbook, ‘If there is no folder for the Stable Tag, then WordPress will default to using the trunk folder’s content’;
    • so the Directory parsed trunk/readme.txt, read in the ‘Stable Tag’ of 2.5.9d1, looked for tags/2.5.9d1, couldn’t find it and so pushed the contents of trunk/ our as a new release 2.5.9d1.

    What Went Wrong

    1. I was unaware that the WP Plugin Directory parsed trunk/readme.txt rather than looking at the latest version release in tags/ — I thought that it was safe to put pre-release code in trunk/, and that the version numbers (two in footnotes.php and one in readme.txt) should be updated to reflect the current version (in this case 2.5.9d1), whereas in fact the ‘Stable Tag’ should remain the latest release version (see example 2.5.6d4 release with 2.5.5 version number here);
    2. @pewgeuges did not know that I was not aware of this (see here);
    3. unfamiliarity with SVN led to me failing to commit new, untracked files (i.e., class/layout/) whilst correctly committing the edited tracked files that referred to them (i.e., includes.php);
    4. my own manual testing failed to detect this due to copying local files into the test environment rather than pulling files from the remote repo; but
    5. as the Directory pushed a new release automatically, there was no time for anybody else to test the changes and notice the error; and
    6. as the 2.5.9d1 release was quickly followed up with 2.5.10, I did not receive an email notification about my own site upgrading to footnotes 2.5.9d1 and realise that there was a problem earlier; and, finally
    7. as I am unavailable this week due to work commitments I have set up an inbox filter automatically moving forum post emails out of inbox, so I was not aware of the flood of forum bug reports.

    Impact Assessment

    This was entirely my mistake due a misunderstanding of how the SVN repo. behaved. It was swiftly fixed by @pewgeuges, but had a significant impact on users (as evidenced by the number of Support Forum posts). The damage appears to be limited to users who have enabled automatic Plugin updates, although as ~50% of the userbase are using the most recent Plugin version, we can infer that potentially as many as 50% of users have enabled this (though the real figure is likely to be smaller). Thankfully, many of those same users will have automatically upgraded to 2.5.10, but some may have disabled automatic updates whilst the Plugin was broken. Hopefully, they will soon see @markcheret’s pinned post above and upgrade.

    Mitigations

    1. Do not update the ‘Stable Tag’ field in trunk/readme.txt for development versions to ensure that committing broken code to trunk/ will not accidentally trigger a release;
    2. add release instructions for future contributors (see here) to ensure that the same mistakes are not made by others;
    3. ensure that commits are kept small to increase the likelihood of errors being spotted (see here);
    4. set up an automated release workflow (see here) in order to completely remove the risk of human error.

      Thank you for reading, and my sincere apologies to anyone inconvenienced by this issue,
      Ben

    • This reply was modified 1 month, 3 weeks ago by Rumperuu. Reason: Fix nested list
    • This reply was modified 1 month, 3 weeks ago by Rumperuu.
    • This reply was modified 1 month, 2 weeks ago by Jan Dembowski.
    Plugin Author Rumperuu

    (@rumperuu)

    Standardised codebase now updated on trunk/ by @pewgeuges (r2484038).

    Moderator Jan Dembowski

    (@jdembowski)

    Forum Moderator and Brute Squad

    @markcheret @rumperuu Don’t post like this. If you have an announcement then let the moderators know and that will get closed. I’ve closed this topic to all replies and archived a few.

    This support forum isn’t your blog, don’t try and use it that way.

    If someone has an issue with the developement version then they can create an issue there.

    https://github.com/markcheret/footnotes/issues/new/choose

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘2.5.10 reverts 2.5.9d1 and apologies’ is closed to new replies.