Developing against Master, and back-porting/cherry-picking to maint if a hot fix is required by someone who needs it before the next release, would certainly be how I've worked in the past.
So moved, white ballot. Unless there's an objection, let's go with that. -- /_ 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: Gary Gregory <garydgreg...@gmail.com> Sent: Monday, January 1, 2024 5:58:49 AM To: dev@xalan.apache.org <dev@xalan.apache.org> Subject: Re: Maven build, thoughts for the new year Happy New Year, I'm not sure I can help with a sanity check since you all have been committing code. What I currently do in other projects is: develop code in branch 'master' which always has a -SNAPSHOT version. When it is time to cut a release candidate, switch to the 'release' branch, merge from master, and work there, not much should happen in the release branch, this is the branch that ends up without the -SNAPSHOT version. If more than one version needs to be maintained, then you can create a '2.x' and 'release2.x' (or similar names) branch when you need it. When I came onboard the Xalan project, there was hardly anyone around to ask what branch means what, so I had take some educated guesses and dig into the repository. You'll find some of that in the mailing list archive. Gary On Sun, Dec 31, 2023, 8:49 PM Joseph Kesselman <kesh...@alum.mit.edu<mailto:kesh...@alum.mit.edu>> wrote: Do you mean 2.7.1-maint or 2.7.3-maint? I thought .3 is our most recent production release, but it's New Year's Eve and I may be confused. GARY, PLEASE SANITY CHECK! The maintenance branch is a maintenance branch for that version. "Hot Fixes" to be released as 2.7.1.x or 2.7.3.x should be merged in there, as well as of course being carried forward into subsequent versions (assuming still relevant). I am honestly not sure whether a merge from an updated 2.7.3_maint to master will still work. In theory it should; git should have all the needed history. If not, we may have to carry some fixes forward by hand. Changes that will be released in 2.7.next, which I would expect to be most of them, should be submitted against master, then back-ported if a hot fix turns out to be needed. Back-porting, IIRC, may involve cherry-picking. ... or may require accepting that parallel pull requests may be necessary. I simply haven't pushed that boundary of Git hard enough to be sure. Master should either be released as next more often or should be check pointed when stable as next.candidate, so we have something stable whenever we want to pull the release trigger. Given continuous development, and availability of older versions, the distinction between candidate and release is pretty thin... Note that while the Maven reorg makes this more visible, the same issue would apply for any change that may overlap work done since the previous release. -- /_ 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: Vladimir Sitnikov <sitnikov.vladi...@gmail.com<mailto:sitnikov.vladi...@gmail.com>> Sent: Sunday, December 31, 2023 5:33:28 PM To: dev@xalan.apache.org<mailto:dev@xalan.apache.org> <dev@xalan.apache.org<mailto:dev@xalan.apache.org>> Subject: Re: Maven build, thoughts for the new year >it's time for you (and possibly others) to start working on that... What is the relation between master and xalan-j_2_7_1_maint branches? Previously, the team said the PRs should be created for _maint branch. Is it abandoned now? How does commit attribution work then? I find it frustrating when maintainers copy others' changes under their names. Vladimir
