Strategies to help developers mitigate breaking changes in 1.0

[nhoizey]

There are multiple things that could be done to enhance Eleventy but require breaking changes.

Would it make sense to release a 0.12.0 version to prepare these breaking changes before they happen in version 1.0?

A build in this 0.12.0 could then generate deprecation/change warnings in the console, without actually changing anything from 0.11.0.

Changes I have in mind:

• Better slugify function: Slug filter doesn't create url safe slugs. #278 (comment)
• Don't ignore files that are in addWatchTarget even if they are in .gitignore or .eleventyignore? (maybe): Allow addWatchTarget to watch ignored files #893 (comment)
• Use objects for options to ease future evolution: Expose inputPath in transforms #789 (comment)

Feel free to comment to add others!

[Ryuno-Ki]

References to Liquid #1334.
I think, I found a reason why it wasn't updated yet, but I can't find the issue.

[edwardhorsford]

Default to including all items from pagination in collections.all

[zachleat]

https://github.com/orgs/11ty/projects/5

[nhoizey]

@zachleat I understand you still think breaking changes in the 1.0 release don't need any previous deprecation/change warning in an intermediate release?

I know some of the changes I would like to see won't be in 1.0, so I'll have to wait for a 2.0… 😅

[zachleat]

I plan to do as much runtime communication in 1.0 as possible. #1390 will be a good example of this. If we detect strictFilters in your Liquid config, we’ll warn you and provide info on what you need to change

[zachleat]

Look for INPUT DIR (if not same as ROOT DIR) .gitignore and warn

[zachleat]

Some work has started on this here: https://github.com/11ty/eleventy-upgrade-help

[zachleat]

Switching to #1393 as the home base for this one! Subscribe over there if you’d like!