Branching Strategy

[kreincke]

Dear Friends;

during the last week - while upgrading from 5.2.3.2 to 5.2.3.3 - we met the need to add fixes to 5.2.3.3 for preventing the users to wait for the next major release (which probably shall be the release 5.3). I am very grateful that you are doing all this extra work. Maybe another branching strategy could simplify this work in the future. Here my proposal (maybe you've used the following rules, but I did not find the respective specification):

** 1. The Meaning of the Release Numbers [pattern 5.A.a.x (= 5.2.3.3)] **

• 5 is the reference-number to Bootstrap and will only be increased, if Bootstrap increases its major release number
• A is the bootScore major release number and will be increased, if and when the team feels that their work contains so many new features that it can stand a new main number.
• a signals that the release contains a minor set of new features
• x signals that the release does NOT contain any new features, but fixes of/for the release x-1

** 2. The Branching Strategy**

[LOOP]

• Starting with the next feature release {in this case 5.3.0, but let's call it RX in this context}, you directly derive a branch integration and a branch maintenance from branch main (= RX).
• The team = you do your development on branch integration just as you did it in the past.
• If there is reported a bug for RX, you try to fix it in the branch integration and/or its sub-branches.
• If you've found a solution for the bug and if it's really serious (your users should not wait for it), you hand over your solution code to your maintainer with a short explanation how to back port it to RX.
• Your maintainer integrates the solution into a sub-branch of maintenance, verifies, that it works, merges the tested solution back to the branch maintenance, does a last check and merges back it into main (RXn).
• When you want to publish a new feature release, you create the release candidate RYC by merging all your improvements into the branch integration. Then you contact your maintainer. He verifies, that all bug fixes of RX which he has released over the time, are now also included into the release candidate RYC. If and when the maintainer has verified that, you (or he) merges integration into main. GOTO LOOP.

The advantage of this procedure is, that

• you can delegate the fixing work without having to interrupt your developing work
• the branch main ever contains the latest stable and tested release RXm ... RXn
• your users can be sure that and how they will get improvements directly.

What do you think about that?

heartfully KR

[crftwrk]

Hello,

firstly, release is here https://github.com/bootscore/bootscore/releases/tag/v5.2.3.4. Including the two bugfixes for sidebar cards and horizontal loop cards. Plus a footer-info widget position where you can add a custom copyright and hide existing copyright via CSS, based on you discussion https://github.com/orgs/bootscore/discussions/389.

What you describe above is semantic versioning. It's very hard not to screw up there and we are both not experts in it. Any help is highly welcome. We need someone to take care of this, are you able to keep an eye on this?

[kreincke]

I am very happy with your work and very impressed by your working style! So: Generally yes. To support you would be a pleasure for me. But I still need some days to complete some open tasks. And the challenge will be on your side: You will decide, what's a bug and what's a feature. And have to be able to say no: that's a feature. If we agree, we will only backport important solutions, I perhaps could participate in your project. Please give me some days to consider the situation.

heartfully: KR