Pressbooks 4.3.4 and Pressbooks Book 1.10.4

Development
1

Originally published at: https://pressbooks.org/blog/2017/10/11/pressbooks-4-3-4-and-pressbooks-book-1-10-4/

We tagged Pressbooks 4.3.4 and Pressbooks Book 1.10.4 on GitHub today and are now deploying them across our hosted networks. Here’s what’s changed: Pressbooks 4.3.4 NOTICE: Pressbooks >= 4.3.3 requires WordPress 4.8.2. NOTICE: Users of the Pressbooks Custom CSS theme must upgrade to Pressbooks Custom CSS 1.0 for compatibility with Pressbooks >= 4.3.0. [CORE ENHANCEMENT] The user catalog title can…

2

Do we use SEMVER for the versions? if so, each time we have a CORE ENHANCEMENT is not the same as a FEATURE?

3

My consideration here is that the two core enhancements in this version are:

  1. Not user-facing;
  2. Fully backwards-compatible.

Bumping the version to Pressbooks 4.4 with a single new “feature” that no users can see (a filter hook that will probably be used very sparingly) is maybe better adherence to semver, but it doesn’t really make sense.

6

I do not really like SEMVER, but if we use, we use. There is a reason for the 3 digits. The last one is just for Bugs, otherwise, we have to write our own specifications for PB and create our own way of versioning and we will avoid misunderstandings.

Now, with the automatic upadtes is more important to have a clear understanding of the new versions. If I see 4.3.4, i think is just a bug, if i see 4.4 i know something is new, and before to update i will take a look the changelog in order to see if i can to update or not.

7

https://twitter.com/dhh/status/550771282372227073

From the linked post:

Breaking changes are no fun, and we should strive to avoid them when possible. To the extent that SemVer encourages us to avoid changing our public API, it’s all for the better. But to the extent that SemVer encourages us to pretend like minor changes in behavior aren’t happening all the time; and that it’s safe to blindly update packages — it needs to be re-evaluated.

If you’re not reading the changelog before updating, you’re taking unnecessary risks. Period. What if you were depending on a bug that I fix, which breaks your code? (This just happened in one of our bugfixes, which patched a memory leak in PB LaTeX but broke Bryan’s MathJax plugin in the process.)

Maybe we won’t use SemVer any more. To be discussed.

8

Also I don’t know what you mean about the automatic updates. You still have to install them explicitly. They just don’t require the GitHub Updater plugin anymore.

9

I mean, i have to do the installation by my action, but as with wordpress. If is a bug update, I use to not care and install. Because If the minor change it was not a problem, a bug change much less problem.