Proposal: Deprecate sections

Feature requests
22

Whats your suggestion to test tera2 with zola?
I saw that in the “next” branch on github, still “tera v1.20.0” is pulled in (cargo tree).

23

It’s not yet ready for use in Zola, still missing some stuff. It’s getting there though, it’s usable on its own if you want to play with it: GitHub - Keats/tera2

2 Likes
24

Official RFC: Proposal: Deprecate sections

All comments are welcome!

1 Like
25

I think the correct link is [RFC] Merging page and section by Keats · Pull Request #3258 · getzola/zola · GitHub :slightly_smiling_face:

26

Thank you, I think RFC process is something that’s been missing from Zola. Would be nice to have a more structured way of discussing such proposals :+1:

27

:person_facepalming: thanks

28

Just a comment on the back compatibility:

I am more in favor of not making the new code able to read the old format, but providing a migration tool, because:

  • the new code does not get bloated (no need to understand the old format)
  • the migration tool is also simpler (no need to understand the new format)
  • the migration tool do not need to evolve: it works on frozen format
  • no deadline on when to drop backcompat: backcompat will be always there in the form of the migration tool. This is important as it reduces the decision stress of the maintainers on when to pull the plug, and no user is left behind even if he does not follow what is happening with Zola.

Also, zola.toml should include a version variable describing the version of zola the site was built for, so the new zola can output an informative message instead of random errors.

29

The backcompat layer is very very thin. Just a few lines of validation to be written. Please comment on the GH PR though

30

The RFC seem OK for me, with two points:

At “Overall, it shouldn’t be a breaking change, except for some narrow cases”, I think it these cases should trigger an error/warning rather than silently fail, to avoid user frustrations.
And maybe this is simpler to implement in a lint/check/migration tool rather than building it into the code at the risk of false positives?

I will have to check once there is a first implementation if my bilingual (FR/EN) section templates still work, which is the part of my site with the most code. From reading the RFC, I cannot anticipate problems issue, so it should work, and thus I have no comment.

31

Those narrow cases are all in the templates and honestly would be tricky to write a migration for that. It would be a few times more work than the actual changes as we would need to inspect all the templates, track variables, where it’s set and field access.

32

I was just advocating for at least raising an error rather than silently failing.

And I was guessing (with no certainty) that raising an error in the code may trigger false positives on valid new syntax. Whereas the migration (or just a simple checker) working only on old syntax cannot have false positives.