[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-tck-dev] Branching and maintenance
|
On 11/19/20 4:28 AM, Alwin Joseph wrote:
Hi Scott/Ed,
On 11/11/20 12:56 am, Scott Marlow wrote:
On 5/14/20 10:55 AM, Ed Bratt wrote:
There has recently been some discussion in a recent PR about the 8.0
branch in the TCK repository. I don't intend this to be commentary on
that specific thread however ...
I just want to put in my vote that we really need a maintenance plan
(branching, release maintenance, etc.) for 8.x. We will need the same
for releases going forward. Our experience is that vendors continue
to require/discover maintenance issues on these releases long after
they are finalized. (Years, maybe even decades. That is life-times in
the life of many projects.)
So, I would urge that a plan needs to be in place and it probably
ought to be documented in a well known location so there isn't
confusion about it and there is the best probability of long term
continuity. Please consider the this so the prospective maintainers,
years from now, will know what to do when they come across those
issues and want to apply their fix.
We do need to document the branching and maintenance plan still.
We have not yet needed to branch our last 8.0 Platform TCK release
8.0.2 but I am thinking that we do need to soon branch the 9.0.0 final
release tag (yet to be created) so that we can use that to release the
5.0.1 Servlet TCK after Jakarta EE 9 is released as final and any
other 9.0.* Platform TCK releases that we need to do.
I think branching makes more sense for Jakarta EE version 9 & 9.1 as we
might have to work on 9.0.1 & 9.1.0 in parallel (and later merge the
9.0.1 changes to 9.1.0).
Do we really need to branch out 8.0 releases?
We can create the 8.0 branches at any time (off of the `8.0.2` tag,
however, currently we only have the master branch.
With an `8.0` branch we could easily refer to the latest TCK sources
under `8.0`, such as:
https://github.com/eclipse-ee4j/jakartaee-tck/tree/8.0/src/com/sun/ts/tests/jstl/spec/fmt/i18n/responseencoding
We could also refer to
https://github.com/eclipse-ee4j/jakartaee-tck/tree/8.0.2/src/com/sun/ts/tests/jstl/spec/fmt/i18n/responseencoding
but that might not be the latest after creating a `8.0.3` release.
I do agree though that we don't have to create a `8.0` branch now, it
would just be nice to have.
If we discover maintenance
issues on the current 8.0 releases (8.0.0, 8.0.1, 8.0.2) can we branch
it out on a need basis to do more 8.0.x releases?
+1, I agree.
I suggest that we base the branch name on the Full Platform TCK
version (major.minor):
Jakarta EE version Platform TCK version Branch Name
------------------ -------------------- ---------------
8 8.0.0, 8.0.1, ... 8.0
9 9.0.0, 9.0.1, ... 9.0
9.1 9.1.0, 9.1.1, ... 9.1
...
Make sense?
Scott
Thanks,
-- Ed
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev__;!!GqivPVa7Brio!JbeC-GnR5tO1v08QkeW7qKFqZy2eHhfT3YIRY4JKuHLzz3pUbFe3l9ysqyEG3NyXrw$
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev__;!!GqivPVa7Brio!JbeC-GnR5tO1v08QkeW7qKFqZy2eHhfT3YIRY4JKuHLzz3pUbFe3l9ysqyEG3NyXrw$