Hi Elliotte, I'm replying to your questions inline below, as per my best understanding. Someone, like Gary may correct me, if he wishes to do so.
On Sun, Jan 29, 2023 at 6:21 PM Elliotte Rusty Harold <elh...@ibiblio.org> wrote: > Looks like master is still quite old but there's a > xalan-j_2_7_3-rc9 that I think is what's being actively worked on. The XalanJ 2.7.3 RC9, should likely won't be finally released, since that RC had few issues as were found during technical review after that RC was released. We've committed to XalanJ repos (implementation and tests repos) the improvements, earlier sometime today, to address all the issues that were found during technical review of RC9. People (the more reviews shall be more helpful) on this list, should review these commits that were done today, and provide their comments on this list. On basis, of any review comments for the current state as of now of xalan-java (branch xalan-j_2_7_1_maint) and xalan-test (branch master) repos, we'll arrive at a decision about when and how to create the next XalanJ 2.7.3 RC (i.e, RC10) which should again be reviewed by people on this list for that to qualify as basis of final XalanJ 2.7.3 release. > What's the current development process here? e.g. where/how should > patches be sent? I think, it'd be best to send XalanJ patches as pull requests (PRs), on github mirror of XalanJ repos, and someone from XalanJ team shall review them and merge to the real XalanJ repos. Anyone, wishing to submit XalanJ PRs, should fork the relevant XalanJ branch on github and submit the PR(s) to be merged to the real repos. > When will the branch get merged to master? My feeling is that, after XalanJ 2.7.3 is released from xalan-java repos's branch xalan-j_2_7_1_maint, we could have options like below, 1) We continue to, develop on the xalan-java repos's branch xalan-j_2_7_1_maint (in that case, merging of branch xalan-j_2_7_1_maint to any other branch is not needed). My personal feeling is, this is simple and best approach, since for XSLT 1.0 implementation development, XalanJ is already quite mature and only rare bug fixes shall be needed. This approach is also ok, since we'll create tag(s) [anyone can download the distributable from tag, to know what was development state when we've made XalanJ release] of the current repos state when making a new XalanJ release. 2) We can create a new XalanJ branch from branch xalan-j_2_7_1_maint, and develop on that new branch. With this approach, xalan-java master branch will remain as it's now. 3) We can merge the XalanJ branch xalan-j_2_7_1_maint to master branch (just to synch the master branch, with latest XalanJ development state), and can continue developing on branch xalan-j_2_7_1_maint or create a new branch from xalan-j_2_7_1_maint for further development. Ideally, for usual development purposes, any code should not be committed directly to XalanJ master branch. -- Regards, Mukul Gandhi --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
