Hi,

If I get it correctly, the suggestion of @danieldietrich was two separate branches, individually maintained to reflect support for bv2 and bv3.

this PR modularaizes the project into BV2 and BV3 - while there is the upside of potentially shared code - I see a downside here: CI and deployment of BV2 and BV3 support should probably be separated.

my feeling is either indiviual repos or individual branches, as they do not/should not have shared code. In the latter case - what is the semantic interpretation of the "master" branch? or is there no master?

Thanks for your feedback @alwins0n.

Yes, you are right. Reading @danieldietrich comment again he indeed suggested to use separate branches. As I was a bit in a hurry I somehow missed that part. Shame on me 🤦.

Let's quickly outline how an individual branch approach could look like:

A release branch strategy is probably a good fit for this problem. So we would have release/bv2, release/bv3 and main. Changes in release/bv2 are auto-merged to release/bv3 and main. Changes to release/bv3 are auto-merged to main. PRs should always target the oldest possible and supported release branch. With this strategy main is always up to date with the latest beanvalidation version. Builds are created from individual release branches.

To be honest, personally I don't think it's worth the effort. Having such a flow means you need to have some GitHub actions in place to do the syncing as otherwise it is very easy to mess up. I don't use GitHub much these days so this might be easier than I think it is. From my experience with other platforms syncing branches using CI tools is a constant hassle. Also there is might a better flow that I'm not aware of.

In the PR I went with a pragmatic approach that keeps things simple. Setting up CI deployment should be fairly straight forward too. I fully agree that CI deployment of different beanvalidation versions should be separated. They probably even should use different images (java 11 vs 17). May I ask what your concerns are regarding shared code?

In the end either approach is viable and it's mostly a matter of preference. We just have to be careful not to pack too much into a single PR. Especially properly setting up CI is an issue for itself I think.