Upgrade to etcd/bbolt #22
Conversation
|
I reverted the initial changes and made the necessary changes to do it this way |
There was a problem hiding this comment.
I think this looks good Sarah. One downside of the v2 thing is that It's hard to tell in this PR whether you actually changed any code or tests here or just copied and switched out the dependency.
Can you confirm if there were any code changes needed so we can look a little more closely there?
Could y
|
Here's a quick little guide on the changes in the v2 folder - Then similarly in the test, changed import - and throughout the test tl;dr - Because of the |
Fuzzy depends on raft-boltdb, which depends on raft as well. Having fuzzy as its own module, breaks the circular dependency. Also, having `fuzzy` avoids leaking the raft-boltdb dependency and versioning constaints into consumers. This was a significant factor, as `raft-boltdb` changed storage engine in hashicorp/raft-boltdb#22. However, given raft-boltdb storage occured as a api major change, and both raft-boltdb storage engines can coexist in the same go project, so it's less of an issue now.
Fuzzy depends on raft-boltdb, which depends on raft as well. Having fuzzy as its own module, breaks the circular dependency. Also, having `fuzzy` avoids leaking the raft-boltdb dependency and versioning constaints into consumers. This was a significant factor, as `raft-boltdb` changed storage engine in hashicorp/raft-boltdb#22. However, given raft-boltdb storage occured as a api major change, and both raft-boltdb storage engines can coexist in the same go project, so it's less of an issue now.
Fuzzy depends on raft-boltdb, which depends on raft as well. Having fuzzy as its own module, breaks the circular dependency. Also, having `fuzzy` avoids leaking the raft-boltdb dependency and versioning constaints into consumers. This was a significant factor, as `raft-boltdb` changed storage engine in hashicorp/raft-boltdb#22. However, given raft-boltdb storage occured as a api major change, and both raft-boltdb storage engines can coexist in the same go project, so it's less of an issue now.
This closes #11.
Fixes #21
Thank you to #12, #19, #13.