touying:0.5.3

[OrangeX4]

I am submitting

• a new package
• an update for a package

Description:

Features

• feat: add strecth parameter for #alternatives[] function class. This allows us to handle cases where the internal element is a context expression.
• feat: add config-common(align-enum-marker-with-baseline: true) for aligning the enum marker with the baseline.
• feat: add linebreaks option to components.mini-slides. feat: add linebreaks option to components.mini-slides touying-typ/touying#96
• feat: add <touying:skip> label to skip a new-section-slide.
• feat: add config-common(show-hide-set-list-marker-none: true) to make the markers of list and enum invisible after #pause.
• feat: add config-common(bibliography-as-footnote: bibliography(title: none, "ref.bib")) to display the bibliography in footnotes.
• refactor: add config-common(show-strong-with-alert: true) configuration to display strong text with an alert. (small breaking change for some themes)
• refactor: refactor display-current-heading for preserving heading style in title and subtitle. [Features] Preserve heading style in title and subtitle touying-typ/touying#71
• refactor: make new-section-slide-fn function class can receive body parameter. We can use receive-body-for-new-section-slide-fn to control it. (Breaking change)
  • For example, you can add #speaker-note[] for a new section slide, like = Section Title \ #speaker-note[].
  • If you don't want to append content to the body of the new section slide, you can use --- after the section title.

Fixes

• fix outdated documentation.
• fix bug of enable-frozen-states-and-counters in handout mode.
• fix unusable square() function. Unable to use square touying-typ/touying#73
• fix hidden footer for show-notes-on-second-screen: bottom. Hidden slide numbering when using show-notes-on-second-screen: bottom touying-typ/touying#89
• fix metadata element in table cells. Alert content wouldn't show in a table touying-typ/touying#77 touying-fn-wrapper is broken inside a grid touying-typ/touying#95
• fix auto-offset-for-heading to false by default.
• fix uncover/only hides more content than it should. uncover/only hides more content than it should  touying-typ/touying#85
• theme(simple): fix wrong title and subtitle. Wrong title and subtitle in (at least) theme.simple touying-typ/touying#70

[elegaanz]

Thanks!

[aaron-jack-manning]

@elegaanz Could we possibly add a checkbox in the pull request template for checking for correct semantic versioning? This package update contains a breaking change which is even listed in the changelog but the update is a patch: 0.5.2 -> 0.5.3.

[OrangeX4]

@elegaanz Could we possibly add a checkbox in the pull request template for checking for correct semantic versioning? This package update contains a breaking change which is even listed in the changelog but the update is a patch: 0.5.2 -> 0.5.3.

Thanks for the comments. Every version of touying basically contains more or less breaking changes, and it is difficult to determine whether a version is a patch or not. My current strategy is that if there's only one or so breaking changes, then I'm not going to add a major version. If you have a better idea, welcome to discuss.

[aaron-jack-manning]

Is there a particular reason why it is undesirable to just make it 0.6.0? I don't see the downside of this, and it has the advantage that I know when it is save to upgrade. I came across this because I updated from 0.5.2 to 0.5.3 only to find a huge number of my slides were broken, but the idea of semantic versioning is that the version number should tell me if that is going to happen.

[OrangeX4]

Okay, that's probably just a difference in perception. Because every update of Touying brings a bit of a breaking update, if you add a major version whenever there is a breaking update (no matter how big or small), the last bit of the version number will not be used at all, that is, every update will not be compatible. I was thinking about whether this version should be called 0.6.0, but in the end I didn't think it was a major refactoring update like 0.5.0, so I ended up just calling it 0.5.3.

I think it's a compatible version with only a small number of users need a few changes. For example, touying's example doesn't encourage you to write the slide content directly under a first-level heading, but rather encourages you to create a second-level heading that users won't run into a breaking change if they follow the examples. Even if you encounter this breaking change, I think you only need to add some --- marks to solve it, so it's an easy breaking change to deal with, and it doesn't involve too many changes.

[elegaanz]

Technically, when you are on the 0.x.y series, semantic versioning does not really have any rules, anything can break at any time.

Still, it is possible to add this checkbox to the PR template. However, in general it is quite hard for reviewers to check that semver is indeed respected: you would have to diff the two versions and understand how the package works, which is just too time consuming. So the checkbox would really just be a reminder for package authors.

[aaron-jack-manning]

@OrangeX4 Thanks for the reply! I don't personally agree but your position is totally fair enough, and perfectly reasonable. While I've got you here thanks for touying btw, I just gave a talk yesterday with slides made using it and it was a joy to use!

[aaron-jack-manning]

@elegaanz That is precisely why I think it would be a good idea to have such a checkbox (independent of my position on this particular instance and major version zero), because it is so difficult to actually verify as a reviewer. Up to you though!