(PTFE-2504) develop branch with three digits

[matthiasL-scality]

PR: Support for development/x.y.z Branches (Three-Digit Development Branches)

Summary

This pull request introduces full support for three-digit development branches (e.g., development/x.y.z) in the GitWaterFlow cascade logic. The changes ensure that the system correctly handles, sorts, and calculates next versions for both two-digit (development/x.y) and three-digit (development/x.y.z) development branches.

Key Changes

• Cascade Logic:

  • The cascade now properly includes and orders three-digit development branches alongside their two-digit parents.
  • When the destination is a three-digit branch, its parent two-digit branch is always included in the cascade, and the order is: three-digit branch first, then its parent, then the rest.
  • The default sorting ensures that for the same major/minor, the two-digit branch always comes before any three-digit branch.

• Next Micro Version Calculation:

  • For two-digit branches, the next micro version is now always the first available micro not already claimed by a three-digit branch, regardless of whether that branch is ignored in the cascade.
  • The logic skips all micro versions for which a development/x.y.z branch exists, ensuring no conflicts or duplicate versions.
  • Each target version is only added once to the list, preventing duplicates when both a two-digit and a three-digit branch would propose the same next version.

• Tests:

  • The test suite has been updated to cover all edge cases, including mixed two-digit and three-digit development branches, correct cascade ordering, and version calculation.
  • Tests now ensure that the cascade and version logic behave as expected for all combinations of present and ignored branches.

Impact

• No breaking changes for existing two-digit or major-only development branch workflows.
• Three-digit development branches are now fully supported and integrated into the cascade and versioning logic.
• Improved reliability and predictability for release and merge automation.

---

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.01%. Comparing base (43d0307) to head (1eea0c0).
Report is 1 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff             @@
##             main     #251       +/-   ##
===========================================
+ Coverage   65.76%   89.01%   +23.24%     
===========================================
  Files          41       75       +34     
  Lines        7922    10028     +2106     
===========================================
+ Hits         5210     8926     +3716     
+ Misses       2712     1102     -1610     

Flag	Coverage Δ
integration	87.46% <98.95%> (+21.69%)	⬆️
tests	87.42% <98.95%> (+21.66%)	⬆️
tests-BuildFailedTest	27.04% <5.59%> (?)
tests-QuickTest	33.92% <66.43%> (+0.99%)	⬆️
tests-RepositoryTests	26.69% <5.59%> (?)
tests-TaskQueueTests	51.89% <52.79%> (-0.12%)	⬇️
tests-TestBertE	66.11% <53.84%> (?)
tests-TestQueueing	53.81% <77.62%> (+0.48%)	⬆️
tests-api-mock	16.19% <1.55%> (?)
tests-noqueue	77.80% <73.42%> (+22.20%)	⬆️
tests-noqueue-BuildFailedTest	27.04% <5.59%> (?)
tests-noqueue-QuickTest	33.92% <66.43%> (+0.99%)	⬆️
tests-noqueue-RepositoryTests	26.69% <5.59%> (?)
tests-noqueue-TaskQueueTests	51.89% <52.79%> (-0.12%)	⬇️
tests-noqueue-TestBertE	62.47% <53.49%> (?)
tests-noqueue-TestQueueing	26.72% <5.59%> (?)
tests-server	29.74% <2.17%> (?)
unittests	40.80% <22.67%> (?)
utests	24.64% <22.67%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[tcarmet]

overall lgtm as it is, but it's hard to tell without seeing some new scenarios in the tests.

ping me when you'll have some so that we can have a look at it and ensure we got all possible scenarios covered.

[tcarmet]

Glad you have some tests now, this gives me a better view of what's up.

Something is up with how you are comparing branches I think. Similar to how development/x are > than development/x.y the development/x.y should be > than the development/x.y.z.
I say this because I see development/x.y getting ignored when the destination is development/x.y.z where I don't think it should be.

What I also think it's missing in terms of tests:

• Are we capable of handling more than one development/x.y.z (I think we are, but need to see it in action). For example development/4.1.17 with development/4.1.18 and development/4.1.

• When the tag 4.1.18 exists and we are working with development/4.1.18 what are we asking in fix version?

• (This one might deserve its own PR and we can try to do it together to minimize changes needed) we should be adding a three digit branch on the base git repo init scenario. Now a whole bunch of tests will break because of it, but it should allow us to identify if we broke something.

  • Kind of related to the above so will implicitly fix itself: Haven't seen any dedicated functional tests with dev/x.y.z branches.

• Since you kept the hotfix branches, if hotfix/x.y.z branches PR + development/x.y.z are into the mix together are we behaving correctly? Can we queue them together? (having a pr of each in the queue)

[tcarmet]

Looking better, still need to see the test cases I mentioned, I added one as a bonus on my review.

For the more functional test setup, we can set one up together in a session if you need a hand on that, over a 30 min session we can get this sorted easily. Just let me know :)

[tcarmet]

I think those two topics need to be solved before merging (second one could arguably be optional but I rather be safe):

• I understand why you removed the functional test we setup, but now we have no functional test that tries to directly target a dev/x.y.z branch as destination. It should work fine, but we have to explicitly test it.
• I also think we implicitly test it, but I do want to see explicitly if we are capable of handling both a hotfix PR and a dev/x.y.z PR in the queue together.

I understand you want to merge this soon, therefore approving but take those into account please.