the next HF is not the right one for this to happen. The next one should be SMTs and only SMTs
ShadowsPub
Looking for writing inspiration? Receive a set of prompts via email every day. Sign up here
You are viewing a single comment's thread from:
the next HF is not the right one for this to happen. The next one should be SMTs and only SMTs
ShadowsPub
Looking for writing inspiration? Receive a set of prompts via email every day. Sign up here
There are already other changes besides SMTs in the hard fork. There is a certain ideal about 'one change per hard fork' but in reality, hard forks are too infrequent for this to work.
This change has the advantage that it is extremely simple in terms of coding, which is an absolute requirement for anything to be considered this late in the development cycle. That makes it feasible to even consider.
Nevertheless there are certainly people who don't want the 4-week change, albeit that seems to be somewhat of a minority.
Everything I've seen and heard is that the next hardfork would focus completely on SMTs due to the extensive changes needed for them.
So what else is being changed?
ShadowsPub
Looking for writing inspiration? Receive a set of prompts via email every day. Sign up here
RC pools is one big thing I know of. I believe there are some improvements to how vote changing works.
I'm pretty sure there are other things but we will have to wait for the release notes to know what they are (or dig through github logs).
Overall the development process is pretty linear. Any work that has been done since the last hard fork and not specifically put on a parallel track (which is rare, since it significantly increases the development effort to maintain parallel code bases) will end up in the next one.