IHP v2.0

[mpscholten]

This is a tracking issue for collecting things that will not ship in v1.0, but might be shipped with v2.0 in the future.

So far:

• Change the routing system to fix existing problems (TODO: note down those problems)

[amitaibu]

We could consider removing the Include feature, which would also mean getting rid of fetchRelated.

This decision is based on the documented reasons outlined here. The Include feature doesn't scale well within the app as it restricts our ability to fetchRelated of child items (i.e get the grandchildren). By removing Include and sticking with the simpler approach, we can maintain consistency across both simple and larger apps.

[mpscholten]

Yes agree, it also will simplify lots of the type signatures 👍

[unhammer]

I use Include all over the place, and I'm not the only one. I'm sure there are good reasons for dropping it, but upgrade churn and backwards incompatibility can easily put people off a project – does the benefit outweigh that cost? If this is to be done, there should be a grace period of communicated deprecation and a clear upgrade path. Is there any way to (partially) automate the migration?

[mpscholten]

We certainly want to avoid doing a python2/python3 split :D We run a lot of IHP apps ourselves, so I always feel the upgrade pain.

Likely we can use a LLM to fully automate the upgrade process in case we have too many changes. Or alternatively we don't change it. (Or we could also add a flag to enable b.c. support)

[amitaibu]

I think that IHP 2 is an opportunity to introduce breaking changes that can mature our codebase. Deleting code, like the Include feature, can be a sign of progress. If we reduce the number of ways to accomplish tasks to a single, optimized method, we can focus on enhancing that approach and providing helpful functions.

We could provide better documentation to guide users on transforming their existing code - specifically, how to replace Include with additional queries.

Regarding backward compatibility, I think we shouldn't introduce a flag to maintain it. IHP is still nimble enough that we can afford to make these changes. So IHP devs are accustomed to minor adjustments between versions, so they won't be entirely surprised by some breaking changes if we're clear in the upgrade docs. Also, it may be worth considering not moving to a full 2.0 version and instead introducing these changes incrementally from one 1.x version to another.