Details
-
Task
-
Resolution: Fixed
-
Critical
-
None
-
None
-
None
-
0.3
-
Build Team 2019 Sprint 18, Build Team 2019 Sprint 19, Build Team 2020 Sprint 1, Build Team 2020 Sprint 2, Build Team 2020 Sprint 3, Build Team 2020 Sprint 4, Build Team 2020 Sprint 5, Build Team 2020 Sprint 6, Build Team 2020 Sprint 7, Build Team 2020 Sprint 8, Build Team 2020 Sprint 9, Build Team 2020 Sprint 10, Build Team 2020 Sprint 11
Description
Problem: libcouchbase is in our manifests, but there is no co-ordination between the SDK and Server teams to determine what changes should be consumed by Server builds, nor any CV which prevents libcouchbase from breaking Server builds or changing functionality unexpectedly.
We need some kind of policy - either Server only consumes released/tagged libcouchbase builds, or there are separate Server-specific branches in libcouchbase, or libcouchbase is required to have CV that ensures correct functionality. This should be driven by Server and SDK dev to decide the best course of action, as several Server teams have a libcouchbase dependency and may have conflicting requirements.
Original description:
Recently for some Mad-Hatter related release process, it looks like the release-2.10 branch on libcouchbase was locked. It should not have been, as this is the branch that ongoing SDK maintenance releases are coming off of.
If MadHatter is looking to lock down to something, it should probably be a specific SHA-1 or tag.