Contracts are versioned according to the SemVer but not really

[cthulhu-rider]

Right now it seems like contracts are versioned in SemVer style. This fact is not fixed anywhere, so I will not accept it as given.

If we decide to use SemVer, then update procedure doesn't look correct to me. Currently, all contracts require new version to be greater than the current one. If major version is greater, then update is OK. But diff major versions in SemVer are incompatible, so it should not be possible to update contract to other major (right now it is)

neofs-contract/common/version.go

Lines 35 to 42 in 6ed3c71

	func CheckVersion(from int) {
	if from < PrevVersion {
	panic(ErrVersionMismatch + ": expected >=" + std.Itoa(PrevVersion, 10))
	}
	if from >= Version {
	panic(ErrAlreadyUpdated + ": " + std.Itoa(Version, 10))
	}
	}

I'd expect a parallel presence of different generations of a fixed contract in the chain (this could require different names in manifest and NNS). In particular, I would have a complete substitution through deployment of the new contract and removal of the old one.

Share ur thoughts about this topic pls, maybe I'm missin smth

[roman-khimov]

diff major versions in SemVer are incompatible

Yeah

it should not be possible to update contract to other major

But why? It may evolve to have new APIs with some minor versions and then drop obsolete ones in a new major. If all of the network is upgraded to use new APIs by the time we move to new major, it's just not an issue.

I'd expect a parallel presence of different generations of a fixed contract in the chain

Only if there is absolutely no other way to solve some problem. I can't think of any particular cases like that now, it should be possible to upgrade without having two contracts side by side.

[cthulhu-rider]

But why?

because existing network will be broken - simple fact which I would like to avoid in reality. New major version means different network, otherwise, this is not a SemVer at all. If contract can be updated with backward compat then there is no reason to release new major. It is far from certain that it will appear at all

[roman-khimov]

You get a major Firefox version every month or so and all of your settings/bookmarks/whatever get upgraded easily with each FF upgrade. You can't go back, true, but you don't need that. Same thing with contracts, I see it as:

• have an X.0.0 version
• release X.1.0 version with some new APIs, deprecate (but keep) old ones
• rinse, repeat with 2, 3 and how many else you need
• upgrade all nodes to be compatible with the latest X.N.0
• release X+1.0.0 that drops deprecated APIs
• upgrade the network to X+1.0.0, no one really notices it since everyone is using appropriate APIs already

This can and should be done in reality, having two versions of the same contract is too problematic. Suppose it's netmap, where do you get your current network map from, how are you synchronizing the two? See #299 also.

[cthulhu-rider]

can't accept FF as a good example since it's a single client app. Contracts are deployed in the network with other parties relying on fixed API and behavior within particular set of major versions. Within single contract, these parties don't expect their project to degrade due to removed funcitonality or smth else. U can't always control all network participants. Upgrade motivation through breakage - nah, not my choice

Again, IF we declare SemVer, but we don't have to

[roman-khimov]

U can't always control all network participants

Well, we've gone through a series of crypto algorithm deprecations in browsers over the recent years. That's kinda the worst possible scenario, not even comparable to NeoFS networks, billions of users with thousands of versions of various software. Were these compatible changes? No. Did things break? Yes, in some minority of the cases they did. Even though the majority of the users receiving regular updates hasn't noticed a thing. And we've survived. And we've solved some problems. Is there any other choice? I doubt that.

For the networks we run we mostly know the participants, even for public ones. And we can declare "version X.Y.Z+ only since some date". And there will be an upgrade. And it'll be SemVer-compatible. And it'll be fine.

You can't keep old contracts forever, it just costs too much to maintain them. But you can gradually update the network in a way that's unnoticeable in the vast majority of the cases.

[cthulhu-rider]

If smth is fixed internally and force-updated on chain - this isn't a new major. Different major version of contracts live on chain in parallel: born and die separately. Otherwise this isn't a SemVer.