Multiple Badger Versions

[aschmahmann]

Problem

Badger releases updates that are breaking changes to the on disk data format, we should be able to create datastore wrappers for each of these data formats. The current state is that we have a new repo per Badger version (e.g. go-ds-badger and go-ds-badger2) this seems like a pretty high maintenance burden and will likely result in code duplication across repos.

Proposal

Let's make branches in this repo are tied to the Badger version. For example, if the latest version of Badger is v3 then we have three branches v1, v2, and master`. Whenever we need to make a modification to a Badger version we push commits to the relevant branch and tag it under the relevant version number.

When we tag versions the major version should correspond to the Badger datastore version. For example, if we need to make an interface breaking change to the v1 badger we would tag the latest commit on the v1 branch as v1.1.0. While this can cause us problems with go get these problems are inevitable since Badger's major versions correspond to the datastore and not the programmatic interfaces anyhow.

Alternatives

• One repo per version
  • Pros:
    • allows us to use major versions to denote breaking API changes
  • Cons:
    • a pain to maintain especially since the code is largely shared
    • we still can get breaking changes from go get because the underlying Badger interfaces can break go-ds-badger
• One folder/package per version
  • Pros:
    • all code is viewable in a single branch
  • Cons:
    • code is duplicated across folders

---

@Kubuxu how do you feel about moving go-ds-badger2 code into a v2 branch in this repo? We can even alias go-ds-badger2 to point to go-ds-badger/v2.

cc @Stebalien @gammazero @mvdan

[welcome]

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment.
Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

• "Priority" labels will show how urgent this is for the team.
• "Status" labels will show if this is ready to be worked on, blocked, or in progress.
• "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

[Kubuxu]

I'm fine with it, we went with go-ds-badger2 to avoid interfering with ipfs development and unblock us on our side.

I'm not sure on the branch vs directory both will create duplication. It would be best if we could transition users from v1 to v2 and actively maintain only the v2, but that is a problem on its own.

[mvdan]

both will create duplication

At the Go module level this is true, but using git branches means that the duplication is easier to handle. One can use simple everyday git commands like git diff to check differences between v1 and v2, or git cherry-pick to backport fixes to older major versions.

[Kubuxu]

True

[aschmahmann]

Cool. Sounds like we have a plan then 🎉.

• Snapshot the current master as a v1 branch
• Create a PR to master switching this repo to match the code in go-ds-badger2 and get review (especially of any non-dependency differences) before merging
• Release go-ds-badger v2.0.0 from master
• Snapshot master to v2
• Create a PR to master switching to badger v3
• Release go-ds-badger v3.0.0 from master

[l0k18]

I forked this repo's temporary v2 version to v3. Only (some of) the configuration options were breaking changes in the API:

https://github.com/indra-labs/go-ds-badger3

I was going to do a PR on it to go-ds-badger2 but I think this was the repo that needs it.

I'm not using outdated badger in my project, and we already have code using v3 so this was all done to eliminate versioning problems especially relating to the badger.Txn type.

I seriously doubt that there is much work in this upgrade in general, just that for IPFS project it seems like it might be spread across a few places that all need to be fixed at the same time.