Closed codemedic closed 1 year ago
@bwmarrin, I was exploring one way to remove parts of code that were marked as deprecated.
I have introduced a config object to configure what was previously done via package level variables.
Having some thoughts about my change here; wonder if the node-id should also be part of the Config
object.
@bwmarrin Any chance you can review this PR.
@bwmarrin I understand you have reservations about changing the current established API.
If that is the case, would you be happy to add go.mod
and call the current version a stable version ( go modules terminology https://go.dev/blog/publishing-go-modules ) with a tag v1.0.0
. That will then allow making breaking changes starting from v2.0.0
onwards. These v2 changes can be kept on a v2
branch, allowing the continued maintenance of both v1 and v2.
I really would like to avoid forking this repo; eagerly waiting on a decision on this and the bulk-generation PR.
@codemedic
I'd like to thank you for the contributions -- it's always nice to see people wanting to help a project.
I've been (and am) pretty busy with work and haven't had time to really think about these changes. I do plan on finding time to seriously consider these and rather I feel they're appropriate additions given the goals and scope of this package. If you need to work off a fork in the meanwhile I would understand. Hopefully I'll get to break away from work soon and can focus on these PRs for you :)
@bwmarrin 👍 I will resist my temptations for some more time then.
These are backward compatibility breaking changes WRT the config aspect. If the client-code does not specify Epoch, NodeBits or StepBits then there is very little ill effect.
Wraps all node config into a config object and moves global settings into a private global config object.