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).
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:
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.
WARNING - The message you received from @sarassandrina is a CONFIRMED SCAM!
DO NOT FOLLOW any instruction and DO NOT CLICK on any link in the comment!
For more information, read this post:
https://steemit.com/steemit/@arcange/anti-phishing-war-the-crooks-continue-their-bashing-campaign
If you find my work to protect you and the community valuable, please consider to upvote this warning or to vote for my witness.
Thanks @arcange that's helpful, lucky enough person is already hidden by a poor reputation. If you can do some help to support my witness work it would be much appreciated. Thanks in advance!
There is more info here:
https://steemit.com/steem/@steemitdev/appbase-the-next-step-forward-for-the-steem-blockchain-let-the-testing-begin
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.