-
|
Two questions we're discussing here:
Ideal outcome of this discussion:
Feedback we have so farv0.34 should become v1From Henry @ Penumbra:
From a user on Discord, they described the problem for SDK, but said the same is relevant for Comet:
So the advantages of v0.34 becoming v1 are clear! DiscussionThere's no strong reason why 0.34 couldn't be 1.0. Part of the reasons why this approach has not been implemented yet:
I will let @thanethomson and @sergio-mena complement the above, as I might miss some context. Release v1 once ABCI++ included
Important is the expectations from users (not necessarily v1)
Preliminary conclusionThere's many things missing in the discussion so far. We'll ask other users to also weigh-in, but some preliminary thoughts would be: Agree on the impact of the problem of having v0.- releases.
Decide which version line (v0.34, 0.37, 0.38) would be first marked as v1.
|
Beta Was this translation helpful? Give feedback.
Replies: 6 comments 10 replies
-
|
I think it makes more sense for ABCI++ to be v2, since it's a big step-change in capability and execution model from the current v1. |
Beta Was this translation helpful? Give feedback.
-
|
This makes sense! It would mean the current v0.38 line would become v2. Is that what you had in mind? To recall: in the current plan, the features that comprise ABCI++ are planned for release across 2 separate (minor) versions:
|
Beta Was this translation helpful? Give feedback.
-
|
No, I think the current version of ABCI should be called 1.0, so that large changes to the execution model (e.g., |
Beta Was this translation helpful? Give feedback.
-
|
As mentioned in #357 (reply in thread), we want our v0.34-compatible release to be as absolutely non-breaking as possible, and we can't anticipate the impact of suddenly implementing a breaking ABCI version bump in what's supposed to be a non-breaking release. The risk is too high at present. |
Beta Was this translation helpful? Give feedback.
-
|
I guess it is clear to everyone, but wanted to echo it just in case: getting over to proper versioning as soon as it safe would be great. I don't particularly care or think it matters a lot in the long term if that is 0.34 or later. The most important part is that we get there, and not in too long. Just want to throw this out there, but to get the "best" (or worst) of both worlds, could we potentially tag 0.34 as both v0.34 and v1? It's ugly and potentially a bit confusing, yes, but it does allow you to both have a safe 0.34 numbering and get to semver asap. I have not thought this idea all the way through, but wanted to throw it out there in case someone sees any good in it :D |
Beta Was this translation helpful? Give feedback.
-
This is a nice insight. We did consider this and discussed it in an internal call. The main hesitation is that it would put our team in the position of needing to maintain multiple versions of the software. This can fragment the user-base across those versions and also give rise to confusion. It's also unclear how we would deal with v0.37 (QA done and it is actively being integrated in the SDK stack). To satisfy all needs, this might require maintaining these versions:
That's 5 version lines. By default, we would need to maintain 3 version lines (.34, .37, and .38) for at least the year to come. This is because we envision stopping the maintenance of .34 in 2024, unlikely we can stop in 2023. We'll continue thinking about it. For the moment, the lowest-disruption (for SDK/current users in production) and highest-impact (for bleeding edge builders) decision seems to be to get onto v1-line after v0.37, so v0.38 would be called v1. |
Beta Was this translation helpful? Give feedback.
-
|
Hi I am that user from Discord quoted in the original post, I'm all in for moving to 1.x asap, here's my points why.
So in short my suggestion is:
|
Beta Was this translation helpful? Give feedback.
-
This, from my perspective, is probably the strongest reason to move to 1.0 as soon as pragmatically possible. |
Beta Was this translation helpful? Give feedback.
-
An element worth adding to @adizere's initial write-up is that we have moved the ABCI version to (post-)1.0:
Two remarks on the ABCI version:
Finally, bear in mind that:
|
Beta Was this translation helpful? Give feedback.
-
|
Since ABCI is already in production, and |
Beta Was this translation helpful? Give feedback.
-
|
In theory, that could indeed be done (i.e., changing ABCI |
Beta Was this translation helpful? Give feedback.
-
While in principle this makes sense, as @sergio-mena says, pragmatically we don't know whose systems we're going to be breaking by suddenly introducing a major version number bump in what is effectively supposed to be a non-breaking release. Beyond this, we currently don't intend on maintaining a legacy ABCI protocol (i.e. pre- |
Beta Was this translation helpful? Give feedback.
-
|
A major version number isn't an indication of a maintenance commitment, though, it's a way to describe versioning compatibility. And while the Informal/CometBFT team may not intend to support it, that doesn't change whether or not it will continue to exist in the ecosystem. (For instance, we were burned badly enough by the 0.35 experience that we have no concrete plans to migrate to any version of ABCI++ until it's in a proven release.) |
Beta Was this translation helpful? Give feedback.
-
|
Dropping this reference here, which I found recently and is very good: https://github.com/tendermint/tendermint/blob/master/docs/architecture/adr-060-go-api-stability.md. |
Beta Was this translation helpful? Give feedback.
-
|
We have decided to release v1 tentatively as the next version of CometBFT. Follow-up with plans here: #578. There's still a few unknowns (in particular proto renaming) but unlikely these are blockers on releasing a |
Beta Was this translation helpful? Give feedback.
-
|
Update: We published the semantic versioning scheme for CometBFT releases with v1 release -- https://github.com/cometbft/cometbft/blob/v1.0.0-alpha.1/UPGRADING.md#versioning |
Beta Was this translation helpful? Give feedback.
We have decided to release v1 tentatively as the next version of CometBFT. Follow-up with plans here: #578. There's still a few unknowns (in particular proto renaming) but unlikely these are blockers on releasing a
v1.