I think that chain-splits are not the most important things, instead the separation or un-consensus of core team's members or communities are.
Splits should be focused on splits inside the core team or communities. It is likely that we all focus on wrong point, simply focus on the effects, not causes of those effects.
Which reasons behind cause chain-slpits.
The important point is here!
The criterion will determine for specific case that we should called it as a hard-fork or an upgrade.
For instance:
If you have a company, which operates with blockchain-based technology, has its own chain.
Some day, you and all members in your company decide to make a change in protocol to do something like: fix security holes, improve the capacity of your company's blockchain with 100 percent consensus.
Will you call it as a hard fork?
There is no separation, it does not have a hard fork, I meant!
Another example in real life.
Some day, you come inside a room, that is totally dark.
Then, you step at the contact, turn them to on position. Unfortunately, the lightbulb does not work, the rooms is dark.
Outside the house, the storm is around for recent hours. What do you think of in the case?
You think that the electricity supply has been down due to the storm, don't you?
But, the real cause maybe the lightbulb, the contact, or the electricity wire inside your house, not outside.
People tend to pay their attention on effects, not causes.
as others pointed out, "hard fork" has a very specific definition. it simply indicates that a fork is not backward compatible with previous versions. it could be implemented by a protocol's core developers, or it could be implemented by random people.
whether a fork could be considered an "upgrade" is a subjective matter. if the fork doesn't result in a network split and it's implemented by developers of the reference implementation, most people would agree it's an upgrade. if there's a chain split, probably not.....
I think that I expressed my opinion better there:
Yeah, over mis-using the term hard fork will create perfect chances for scammers, who will readily - of course - use the term for their shitty clone forked projects.
Before using the term hard fork, I think there are two main criteria should be taken into consideration:
1> Purposes of the event (I got those three ones below from the new-source there:
https://cointelegraph.com/bitcoin-cash-for-beginners/what-is-hard-fork#terms-you-should-know)
1. To fix important security risks found in older versions
2. To add new functionality
3. To reverse transactions.
If the purpose is compromising open source code of others and use them to create new coins, it should be called as clone fork, not hard fork.
2> The separation of core team or communities or not (for projects that have full control of their core team, communities will not play a role in the criteria).
....
I totally agreed with you.
a breaking change in the protocol (an update)
and, it should be sticked with one supplementary criteria, a separation or un-consensus of core team or communities (for community-driven projects) on the update/ upgrade.
Our lives are trial-and-error learning process, so the topic is open-discussing.
I have still thought that it is time to add some strict criteria to the term hard fork.
It is the same situation when Galileo Galilei demonstrated his theory of tides to defend that 'The sun does not circle the Earth, but the Earth circle the Sun'.
Terms/ definitions created by people, and can be misused by people as well.
