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> 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> > *Sent:* Sunday, December 31, 2023 5:33:28 PM > *To:* dev@xalan.apache.org <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 > >
