Updated decision - Badger release process - #16 by ibrahim
We currently merge Badger master into Dgraph before its patch and major release. Going forward we propose to do away with this model.
For Dgraph patch releases, we want to avoid this practice as it introduces lot of changes that do not belong to a patch release. The expectation from a patch release is to fix problems observed by users and do it frequently (vs a major release) without compromising its stability. Minimizing the changes that go into a patch release is a step in this direction.
For Dgraph major releases, we want to benefit from the wide use of Badger in the open source community and avoid using Dgraph as the primary vehicle to try out the changes and uncover issues.
We are proposing to move Badger to a calendar release version system used by Dgraph. This would allow us to not mix Badger bugs that needs to be incorporated into Dgraph patch release with Badger improvements or new features that needs to go into Dgraph major release. This would increase the number of Badger releases.
We would target Badger major releases a month before Dgraph major release. This would allow us to use a stable released version with Dgraph. This would start with Dgraph 20.11 release. Patch releases of 20.11 would use the corresponding patch release of badger as needed.
We still need to continue with our current focus on adding stress, longevity and scale testing to do a better job on uncovering bug fixes before they are released to customers. For dgraph 20.03 patches and 20.07 major release, we would use a stop-gap badger branch that would have the bug fixes made in June and July