Hi, Alexander! Sure, 10.2-ext or 10.3-base - whatever you prefer. I understand that bb-10.2-compatibility will be eventually pushed into 10.3 too, when it'll be ready. For now, I'd suggest the following: 10.2----------------------->10.3 \ \- 10.2-ext ---> 10.2-compat and eventually 10.2-ext and 10.2-compat are getting merged or rebased into 10.3. Other features that depend on your refactoring and need be in the compat branch, can be pushed directly into 10.2-ext. Are there features that should not be in 10.2-compat but still depend on your refactorings? On Dec 16, Alexander Barkov wrote:
Hello Serg, all,
A few weeks ago I created a new branch "10.3" and pushed essential patches needed for the compatibility project.
It worked as follows: - In 10.3: git rebase origin/10.2 git push --force
- In bb-10.2-compatibility: git rebase origin/10.3 git push --force
Now as other developers start to push into 10.3, this won't work anymore. We briefly discussed with Monty that, as the compatibility project should be as stable as possible and merging all 10.3 patches into bb-10.2-compatibility is not desirable, we could try something like this:
Add a new branch (Monty proposed "10.3-base" as the name) and propagate changes as follows:
- In 10.3-base: git rebase origin/10.2 git push --force
- In bb-10.2-compatibility git rebase origin/10.3-base git push --force
- In 10.3: git merge origin/10.3-base git push (no --force)
10.2 ---(rebase)--->10.3-base--(rebase)-->bb-10.2-compatibility | | (merge) (merge) | | V | 10.3<-----------------/
Any objections about this scheme?
I'd only propose to use "10.2-ext" instead of "10.3-base", as this intermediate branch is going to be more 10.2 than 10.3.
Regards, Sergei Chief Architect MariaDB and security@mariadb.org