List of fixes: All the change sets going into the main branch have the issue number in their title. Pull a list of them to get that enumeration, factoring out the work items for Maven cutover.
You can merge/rebase from master into your branch to pick up those changes. If you really don't want to accept the Maven work, you can try cherry-picking the changes you do want... but I would strongly recommend rebasing, since if we ever do converge the two branches we'll have to do that, and it only becomes harder as we delay that work and possibly introduce conflicts. To make Xalan a _real_ 3.0 processor we'd have to rework some of the core data model in addition to adding functionality. (The distinction between temporary trees and nodesets must be maintained in 2.0, and must be eliminated in 3.0, for example). What your work gives us, I believe, is a processor with 2.0 semantics to which some of the 3.0 features have been added. Which is an interesting thing, but it isn't 3.0, and I think the combination permits stylesheets that can't be reliably run on other 2.0 _or_ 3.0 processors. I would ***much*** rather force the user to be aware of that when writing the stylesheet than get into arguments about it later. Hence my desire to give them a separate namespace. That's what I would have recommended if I'd seen the start of your work; I still think it's the best available solution. If I had the cycles I'd offer to do the rename for you, but this summer has acquired a large pile of interrupting priorities and I'm having trouble breaking free and focusing on code. I still have at least one item to do before master (with Maven) is released at all, since Gary said he feels retaining Xalan-Test in the binary distribution is important. Before anything else, we wanted to get that "final ant build" version released, with code current as of just before the Maven cutover.. I don't think anyone has done so yet...? -- /_ Joe Kesselman (he/him/his) -/ _) My Alexa skill for New Music/New Sounds fans: / https://www.amazon.com/dp/B09WJ3H657/ Caveat: Opinionated old geezer with overcompensated writer's block. May be redundant, verbose, prolix, sesquipedalian, didactic, officious, or redundant. ________________________________ From: Mukul Gandhi <gandhi.mu...@gmail.com> Sent: Saturday, June 22, 2024 1:11:55 PM To: dev@xalan.apache.org <dev@xalan.apache.org> Subject: Re: Xalan-J release discussion Hi Gary, Thanks for the thoughts. On Sat, Jun 22, 2024 at 5:12 PM Gary Gregory <garydgreg...@gmail.com> wrote: > I don't think we should release new features in a maintenance release like > 2.7.x. A new feature should be in 2.x.0. Or it maybe be worth saying this is > 3.0 which would happen to match the "3" of XSLT 3. I'll be happy with whichever Xalan-J release numbering scheme you all may decide, for Xalan-J's XSLT 3 work that we're doing. > I would expect (YMMV) that a new feature release would also contain all > current bug fixes from the 2.7.x branch. What are these bugs? Where is list of these bugs available? I think, Xalan-J's dev repos branch xalan-j_xslt3.0 was created from the repos branch from which we released Xalan-J 2.7.3 version. -- Regards, Mukul Gandhi --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
