Can we have unofficial de-facto commit "releases"?

[Supermath101]

This stems from #2972, point 7. The primary benefits include:

1. A target for plugin developers to develop for, without being stuck on 0.5 practically forever.
   • This also gives extra time for plugin developers to adapt to the new changes of every few PRs or so, instead of implementing all the needed changes at once right after release.
2. This should be a commit ID that is kind-of verified to at least build properly. Might need some effort for that to be the case, though.
3. This shouldn't ruin the hype-train, whereas an incomplete actual release would.
4. This would replace the need to point your Cargo.toml to an arbitrary commit in the main branch (in most cases).

I was discussing this on Discord, and it seems that this would be a very uncontroversial thing to temporarily(?) implement immediately. Please react with a thumbs up if you are in agreement, or thumbs down if you disagree.

[alice-i-cecile]

In terms of which commit to pick, there's one important controversial choice.

#2254 (derive Component) is both controversial (see #2966) and requires very aggressive changes from plugin authors. If we decide to pick a commit before that, it should be just prior. If it's after, it should be as fresh as possible.

Personally, I think that there's strong benefit to trying to target a commit afterwards: it allows us to properly assess the impact of the change, and see how painful it is in practice.

[Supermath101]

Correct me if I'm wrong, but a third option would be to create another branch without the derive Component implementation merged in, and point to that, right? Not saying that this is the best option, but at least we'd have most of the latest features, but without the hassles or downsides of derive Component. This would only be temporary though.

[ManevilleF]

Is deriving Component controversial? Why?

[alice-i-cecile]

a third option would be to create another branch without the derive Component implementation merged in, and point to that, right? Not saying that this is the best option, but at least we'd have most of the latest features, but without the hassles or downsides of derive Component. This would only be temporary though.

Yep, this would work. However, it has significant upsides as well, and seeing how manageable the downsides are would be very valuable.

Is deriving Component controversial? Why?

It prevents you from adding bare external types as components. This can be somewhat tedious if you have a large number of external types. Rapier in particular has expressed concerns about this. #2966 gets into the details more.

[wilk10]

One thing that is not clear to me is whether this proposal is to become a regular part of the process together with the 3 months train releases that is being discussed, or if it's meant to ease the pain right now while waiting for 0.6.

If it's the former, in my opinion it risks creating more confusion and overhead, cause if it's not clearly communicated you risk still having plugins targeting different commits (but at a lower chance than now), and you'll get people asking "but why not a normal release?" quite often.

If it's the latter, maybe there's a conversation to be had if 0.6 has to really be the one where the new renderer lands. I understand it involves substantial backtracking, but maybe it's just worth talking about it without discarding the idea immediately (FWIW i probably think we should just wait and improve the process going forward, but it's good to weigh it openly perhaps).

[ManevilleF]

Maybe 0.6 should be split into two releases. It is not a great practice to have such big scopes