You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
I was reading #2082 and I wanted to add in a couple alternative ways to update leptos_axum etc. to support axum0.7:
Unsynchronize the versions of leptos and the supporting crates and use version metadata to communicate compatibility with leptos. For example, leptos_axum would then release a new version 0.6.0+axum-0.5. Each release could also clearly state in the docs which version of leptos it is compatible with. The only downside to this mentioned in the PR was that it would cause confusion as to which version corresponds to which, but I think this problem is solvable by these two steps.
Release and maintain pre-release versions of crates like leptos_axum that contain up to date dependencies. Since pre-release versions are unstable, a leptos_axum version 0.6.0-alpha doesn't need to be compatible with the eventual 0.6.0.
I feel that the current situation is awkward because it's not unlikely that there will be more cases where a breaking release of a supporting crate is warranted, whether it be a dependency update, a bug fix or something else. As leptos becomes more stable, the wait between major releases is naturally going to grow longer, and so such updates to supporting crates will have to wait longer as well with the current scheme.
In any case, just waiting for 0.6 or using a temporary fork aren't bad options, so it's not a huge deal, these were just some thoughts I had.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Hi,
I was reading #2082 and I wanted to add in a couple alternative ways to update
leptos_axum
etc. to supportaxum
0.7
:leptos
and the supporting crates and use version metadata to communicate compatibility with leptos. For example,leptos_axum
would then release a new version0.6.0+axum-0.5
. Each release could also clearly state in the docs which version ofleptos
it is compatible with. The only downside to this mentioned in the PR was that it would cause confusion as to which version corresponds to which, but I think this problem is solvable by these two steps.leptos_axum
that contain up to date dependencies. Since pre-release versions are unstable, aleptos_axum
version0.6.0-alpha
doesn't need to be compatible with the eventual0.6.0
.I feel that the current situation is awkward because it's not unlikely that there will be more cases where a breaking release of a supporting crate is warranted, whether it be a dependency update, a bug fix or something else. As
leptos
becomes more stable, the wait between major releases is naturally going to grow longer, and so such updates to supporting crates will have to wait longer as well with the current scheme.In any case, just waiting for
0.6
or using a temporary fork aren't bad options, so it's not a huge deal, these were just some thoughts I had.Beta Was this translation helpful? Give feedback.
All reactions