Stuart,
I agree that we should have a relatively short process to 5.1.
So after thinking about this a bit more I think the biggest issue is going to be how we handle the TCK. I don't think we should have projects pushing work on progress into the upstream TCK repo as it is shared by all projects. Each project could have their own development branches, but if every project is working on different branches the pull request queue + permissions would be a huge mess.
Ideally I think we would want a Servlet fork of the TCK repo, with branches for each Servlet version. That way we can control the repo, and the main repo is not full of work in progress branches. These updates can then be merged back into the main repo when they are complete and the main repo is ready for them. I assume the main repo will want to be in sync with whatever the current platform version of things are, e.g. if there is a Jakarta EE 10 with Servlet 5.1, but we have done Servlet 6, I am assuming the main repo should stay on 5.1 to make it possible to certify the platform, while we maintain Servlet 6.0 separately until the platform is ready for it. This assumption is not based on anything concrete, just my gut feeling about how it could work, so I think we need a broader discussion about this.
Another pain point will be what are we going to run the TCK against? IMHO we really need to have at least one container passing the TCK to give us confidence that things are correct. In the past this would have been the RI, but I certainly don't have time (or any inclination) to work on Grizzly and I am pretty sure everyone doing the work will be in a similar boat (we have our own containers to work on). Does anyone know what the new requirements are here? Do we need to have Glassfish + Grizzly passing the TCK in order to release a new version?
In terms of 5.1 I was basically just thinking about going after any low hanging fruit + SameSite. I think most of the work is going to be setting everything up and getting comfortable with the process.
To keep email threads simple, maybe we should create a new github issue tag called "NextReleaseCandidate", which any committer can apply to an issue they think should be considered. We can then all review and discuss within the issue and once rough consensus is achieved we either add to the project or remove the label.
Sounds good to me.
Stuart
Hi Everyone,
I would like to propose that we branch the current master into a 5.0.x branch to track any additional changes required for the 5.0 release, and change the current master to target 5.1 so we can start to do some actual spec work.
This also brings up the question of what exactly will go into 5.1, what is the time frame we are looking at, and what will be our planning/release process in general going forward?
I was thinking in terms of planning and release timeframe we adopt an informal planning process based around group consensus. After a release has been done we send out an email asking for input on what should go into the next version, and what the timeframe would be. Once we have a general consensus we just make this publically available somewhere (github wiki maybe?), and start work. The aim of this planning process would be to set expectations based on timeframe and features, but it should not generally be used to to exclude any other additional work that is ready..
My feeling is that 5.1 should work on a relatively quick release cycle, with the main goal being to get the SameSite cookie support, with everything else we can include just being a bonus (everything else in this case likely being working through the issue backlog and attempting to clarify things).
Thoughts?
Stuart
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev
--
_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev
