[servlet-dev] Managing the EE4J_8 Branch

[Stuart Douglas <sdouglas@xxxxxxxxxx>]

Hi Everyone,

I would like some feedback on how to best manage the EE4J_8 branch.

Greg left a comment on https://github.com/eclipse-ee4j/servlet-api/pull/211 about PR's from private repos to the release branch.

I am not 100% sure what Greg means, but I think the implication is that work is done on the master branch, and then a PR is opened from master back to EE4J_8?

I am ok with this approach in theory, however at the moment it is not really workable as master contains some commits that are not suitable for the EE4J_8 branch.

In particular:

https://github.com/eclipse-ee4j/servlet-api/commit/49b41637e8dfebaab9f19d3179f0f8d58405b3e3

We have been asked to refrain from adding Automatic Module name for now

https://github.com/eclipse-ee4j/servlet-api/commit/2cab180146e300bf9d361ac9a313fd7015a6f49f

https://github.com/eclipse-ee4j/servlet-api/commit/7ee900a78b2679bf7c9a4c83633eda36acc657f3

These break the TCK signature tests (I have confirmed locally that these tests pass against WildFly with these commits reverted).

So as I see it we have the following options:

1) Just cherry-pick the commits we want back into the EE4J_8 branch. This means there is no merge commits from master back to EE4J_8. Every change that needs to go in both will need two seperate PR's.

This does not really seem practical, as in theory we should be running the TCK against everything in the EE4J_8 branch.

2) Temporarily revert the problematic commits in master, use master as our working branch for changes for the EE4J_8 release.

This means for now we only commit changes that are relevant to this release, then open a PR from master back to the EE4J_8 branch when we are ready to release.

3) Create a EE4J_8-dev branch, to stage all EE4J_8 commits.

This is basically similar to approach 1), but with an additional staging branch, so we can limit the amount of TCK testing required.

For what it is worth my preferred approach is approach 2). Basically revert everything that is not suitable for inclusion in the first release, focus on getting the first release done, then start looking at upstream changes once we have a first release. Autoamtic-Module-Name can go in a minor release once there is consensus on what we should be doing there, and changes that affect the signature tests can wait until the TCK has been properly open sourced and the tests can be updated to reflect our changes.

Thoughts? I would really like to get some kind of consensus on this so we can start the release process.

Stuart