Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jaxrs-dev] Branches

Hi everyone,

I know that this has been discussed before, but I've some concerns about how branches are currently set up in the jaxrs-api repository.

Beside the required "EE4J_8" branch, there are 4 other branches:
  • master
  • 2.1.1-SNAPSHOT
  • 2.2-SNAPHOT
  • 3-SNAPSHOT
I think this setup is confusing for a number of reasons:
  • It is not clear which the main development branch is. People tend to think that everything should go to "master", but actually commits will most likely need to go to 2.2-SNAPSHOT.
  • It is not clear into which branch changes should go. Should everything to 2.2 and we just cherry pick commits to 2.1.1? If we commit fixes to 2.1.1, how to we also get them to 2.2 and 3? Raising pull requests against all affected branches seems to be an overkill.
  • The "master" branch is currently effectively unused. Critical bug fixes will go to "EE4J_8" and further development to the SNAPSHOT branches. So what is master used for?
  • Having two branches 2.2-SNAPSHOT and 3-SNAPSHOT for the "next version" is confusing. We don't know what version comes next, so I don't think that we should start to work on separate branches. And everything that goes into 2.2 should also be in 3. How do we make sure that nothing is missed?
I wonder if we shouldn't simplify the branch model. I was thinking about only 2 branches (beside the required "EE4J_8" of course):
  • "master" branch:
    • This branch will be the main development branch. All PRs are raised against this one, even critical bug fixes. Just like everyone would expect it.
    • This branch represents the "next version". It currently doesn't matter if it will be "2.2" or "3.0". We can decide on this later.
  • "2.1.1-SNAPSHOT" or "2.1_MR" branch
    • No pull requests will be raised against this one. Instead, critical fixes are cherry picked from the "master" branch. The same process can be used for getting fixes into "EE4J_8" if required.
    • This branch would act as the basis for a potential maintenance release. Whether such a release will ever happen can be decided later.
As you see, this model is MUCH simpler. And I think it is not confusing for anyone, because it follows the standard pattern to have a master branch for active development and maintenance branches which can get bug fixes from the master branch. And the branch model will be compatible with the rules published by the PMC if "master" is a protected branch.

What do you think?

Christian




Back to the top