# 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 now be changed via the pb_catalog_titlefilter (props to @monkecheese; see #961).
• [CORE ENHANCEMENT] SCSS variables from theme options will now be passed to the SCSS compiler as key/value pairs rather than by building SCSS in PHP (see #782 and #963).
• [FIX] Fixed an issue where the PDF margins theme option was not being applied properly.
• [FIX] Fixed a conflict between the updated Pressbooks LaTeX module and third-party renderers (props to @monkecheese; see #958 and #959).
• [FIX] The publication date should now save properly, regardless of book language (thanks to @thomasdumm for the bug report; see #965 and #966).

## Pressbooks Book 1.10.4

• [FIX] Fixed an issue where part numbering would not reset properly in Prince if the part was the book’s first content (see #45).

## Notable Replies

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

2. ned says:

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.

3. 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.

4. ned says:

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.

5. ned says:

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.