Make the community build a single-branch repo

[dwijnand]

For one, this would mean that merging commits, even to a branch that isn't the default branch (e.g. the "2.11.x" branch when merging #481), which states "Fixes #480", properly closes #480.

I believe the problem is related to Jenkins(?), but I'm not sure what the details are, so let's talk.

[adriaanm]

We can't build the same set of projects on 2.11.x and 2.12.x, so this will have to be fixed on github's end. I logged a support ticket about this a while ago

[adriaanm]

Our CI is set up under the assumption that the 2.11.x/2.12.x etc branches exist across repos

[dwijnand]

I meant by having multiple configurations (eg 2.11.x/2.12.x/2.13.x) in the same branch.

By "across repos" do you mean between this repo and scala/scala?

[adriaanm]

yes, jenkins checks out the 2.11.x branch during a build flow across many different repos

[adriaanm]

I agree it's a disappointment that github doesn't support this yet, but I assume there's many repo setups like ours

[retronym]

We probably don't do it in this repo, but, as we do in scala/scala, we should really merge 2.11.x -> 2.12.x -> 2.13.x (even if many of the changes are discarded with git merge -sours).

[dwijnand]

Btw, that was only one reason for a mono-branch setup. I'm sure for day-in-day-out maintenance of the community builds it's a major PITA. This isn't just the GitHub thing.

[SethTisue]

we should really merge 2.11.x -> 2.12.x -> 2.13.x (even if many of the changes are discarded with git merge -sours)

I do in fact do those merges! Actually 2.11.x -> 2.11.x-jdk8 -> 2.12 -> 2.13

I'm sure for day-in-day-out maintenance of the community builds it's a major PITA

sort of... not that much actually. the two 2.11 branches are pretty stable these days, changes are rare. I have to merge 2.12 stuff forward onto 2.13, but it's nbd. making parallel edits in two files on the some branch wouldn't really be notably easier I don't think.