Beta folder vs branch

[philstopford]

I was surprised to see the Beta folder approach in the repository. Normally, one would expect a branch to exist for specific activities/development versions as the need arises.

I tend to have branches for release versions to allow me to conveniently recover a stable version for patching, and have the main branch as the development version. WIP and/or experiments go to dedicated branches that I can merge or discard as they work out.

Just a suggestion in case it helps.

[AngusJohnson]

Thanks for the suggestion Phil.
I'm still pretty new to github and only slowly working out the best way to do things.
Would you make the release branch the main branch or another, and how often would you update the release branch with running patches? And do you perform CI testing on the release branch or the main branch or on both (if they're different) branches)?
However, I can see that branching early releases of a major update makes sense.

[philstopford]

I don't have CI infrastructure for my stuff - I have a bunch of tests which get run manually because I don't have the interest or skill to throw the test system together.

What I tend to do is have the main branch as the live development code, and with each release I create a branch and tag. That means that I can continue working on the main branch and switch to any given release to fix up things. I try to make commits as specific as possible, with detailed commit comments, to allow me to merge specific fixes or enhancements between branches if needed (e.g. a fix from the in-work code needs to be applied to a stable branch). Branches can also be used to capture the code before a breaking change (e.g. a change of contract, interface change, whatever) is made, so that any dependent project can work from that branch without needing to follow the major changes (which could be out-of-scope for that particular project at that particular point in time)

Where I diverge from this overall scheme is experimental work - I will create a branch to contain the experimental work in isolation. I will then work on that experimental branch until either it looks halfway decent or it fails miserably. Then I'll merge the changes with a PR back to the main branch, or simply nuke the branch without that merge. In that way, I don't have to unpick things later if something doesn't work out.

I also like the small commit and branch workflow to allow for bisecting fails. With huge commits, it's very difficult to isolate the point of breakage within a commit. Having the ability to see the wood for the trees is invaluable in quickly triaging problems.

[philstopford]

There are different schools of thought. https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches might be a good reference and has some links to other resources.

[AngusJohnson]

Hi again Phil.
You've probably seen that I've now created a Beta branch for the new Clipper2 ver 1.1.
I've also done a fair amount of testing (though not so much for the C# translation) and it seems pretty solid.
However, while the github repository's CI testing currently fail (C# and C++), they pass on my Windows PC so I'm assuming that it's something trivial.

[philstopford]

Yes - thanks. I'm just coming to the end of a local major refactoring to adopt the ClipperD approach across my code. Once I've got that squared away, I'll kick the tires on 1.1. Hopefully in the next day or two :)

[philstopford]

So far, 1.1 code seems fine in my local tests; still poking at it.

[reunanen]

Same here: 1) looks good so far, 2) still poking.

[AngusJohnson]

Thanks guys, I really appreciate the feedback. I'm hoping to significantly improve horizontal merging before merging Beta into main. (The new C++ example app RandomClipping2 (DoSquares routine) well demonstrates the deficiencies there)

[AngusJohnson]

Here's a test that fails because of trying to dereference a null pointer: [Tests_56688.zip]

It's probably to one I've just spotted myself and hopefully fixed now. 🤞
Bedtime now so I'll check in the morning 😁.

[reunanen]

Here's another null pointer problem: Tests_30588.zip

[reunanen]

Looks good now! Will do some extended testing.

[AngusJohnson]

Thanks again Juha. I'm still anticipating another bug or two 😁. And although horizontal merging is way more complex than I'd expected, IMHO merging in general is not nearly as complicated as it was in former Clipper iterations.

But, unrelated to that, I'm still not happy with how polytree ownership is being resolved. It's messy and probably very inefficient too.

[AngusJohnson]

Are you basically done for the time being, or do you still have something to work on in the latest beta version?

I've just done another signficant revision of the horizontal merging as I still wasn't really happy with it.
This new version does a much better job and the code is simpler too.
This is done and well tested in Delphi and it's mostly translated to C++.
However the C++ translation will need a lot of testing before uploading.
And of course there's C# to translate too, but I'll probably upload the Delphi and C++ versions initially.

[AngusJohnson]

I'm now very close to merging/promoting the Beta branch to the main branch.
I'm not aware of any outstanding issues with it and I'm pretty happy with the improvements (especially to polygon merging).
I guess this is a last minute call to those who've been able to test the Beta to report any surprises before I unleash C2 1.1 on the metaphorical masses. (Since I've just made a number of recent changes, I won't merge the Beta for a few days to give time for additional feedback.)

[AngusJohnson]

The Beta branch has now been merged into main.