Witness Update - @crt - 03.05.2018

in #witness-update6 years ago (edited)

New Update: Addressed by @timcliff, versioning works based on HF


Today I updated all my nodes towards 0.19.3

I was thinking of going with 0.19.4 - Release Candidate, however, there are some observations that I would like to point out. (in regards to 0.19.4 Release Candidate).

changes.png

While improving the code base is out of any doubt something that is necessarily, I noticed total lack of backward compatibility. Taking into account file sizes of full nodes, many of us are using specialized storages. In ideal world, each new version shall be backward compatible, especially when it comes to minor changes.

Messing with API, such as removing login_api shall definitely be a mayor version change not the minor one, and definitely not the "patch level" one. With such radical approach, I would rather expect to see it to resolve as 0.2 rather then 0.19.4

The gives impression of backwards compatibility, causing unnecessarily downtime. Even in major changes, backwards compatibility is still important. There should be at least few minor if not major version where function is deprecated, rather then removed.

In overall, non following the good industry practices in versioning only gives impression of immature project towards potential developers.I strongly believe we should all pay more attention to quality and good industry practices, rather then changing everything from the ground up, just because some of witnesses are used to condenser.

This makes extremely difficult to maintain the system with custom scripts that would fail or partially work with each minor version change. As a result, we can push away many experienced system administrators from possible witness work, as we already do with docker setups and similar approaches to bridge the gap for new linux users and compensate time needed to learn. As a result, blocks are missed and overall network stability suffers.

To recap, a minor version change, of 0.19.3 -> 0.19.4, that is optional, but induces significant architecture changes (therefore could not be optional), moreover, not backward compatible, is not correct versioning at all.

In my opinion, we should stick with good old, MAJOR, MINOR, PATCH versioning, rather then inducing architecture changes in something that should be a PATCH by version number.

Take this as a positive criticism to make things better.

Best Regards,
S.


If you would like to support my work, please do by voting:

vote.gif

If you are an advanced user, You can do it with unlocked cli_wallet by executing:
vote_for_witness "yourusername" "crt" true true

Thanks to all supporters and all the members of Steemit Community.

Sort:  

Thanks @timcliff

Actually the HF based versioning you explained makes sense. As long there's a standard, all is good. Thanks for giving a hint on steemchat.

Boost Your Post! Its FREE! steem.link/ned

Coin Marketplace

STEEM 0.17
TRX 0.15
JST 0.028
BTC 57135.10
ETH 2349.23
USDT 1.00
SBD 2.39