Anyhow it's a minor nuisance. I'd rather get feedback in the feature branches. I'm pretty sure they are done and ready to go, aside from the change log and release updates
On Sat, Nov 15, 2025 at 7:01 PM Alex O'Ree <[email protected]> wrote: > > but I can't see how to automate the -git- number. > > i've used this before. It's not exactly sequential but it follows the > repo's commit counts. > > https://github.com/alx3apps/jgit-buildnumber > which adds all the git info available as maven properties > then this plugin > https://www.mojohaus.org/templating-maven-plugin/ > and a template java file in /src/java-templates/package/Release.java for > example > using something like > > public static final String VERSION="${project.parent.version}"; > public static final String HASH="${git.hash}"; > public static final String HASH="${git.branch}"; > public static final String TAG="${git.tag}"; > public static final String COMMITS="${git.commitsCount}"; > > It's a step closer, but not exactly what is done currently. There might be > a way to extract the git commit message log to put in the changes.md...I > know there's a maven report plugin that does that. And of course there's > the good old, use the jira generate notes too. Oh i think there's a jira > reporting plugin that can do it, so long as you're online. Basically you > can search for tickets with the fix version == whatever and then generate > some output from it. > > might have been this one > https://maven.apache.org/plugins/maven-changes-plugin/jira-report-mojo.html > i stopped using it a long time ago since the corporate jira server is > behind a firewall and it wasn't possible to run the queries through it > unfortunately. it might actually work for the asf one since it's public. > > On Sat, Nov 15, 2025 at 6:34 PM Juan Pablo Santos Rodríguez < > [email protected]> wrote: > >> Hi Alex! >> >> Thanks for the quick turnaround, and for also fixing the site build! I >> agree, the changelog + version bump is kind of a PITA to maintain between >> branches. In my case it's always my last pushed commit, and usually from >> master itself. >> >> I wonder if this could be automated somehow, Release.java could read from >> an autogenerated file all the version data, but I can't see how to >> automate >> the -git- number. Using the commit hash could be an option, but for me >> that >> loses clarity.. Don't know what could be the best option :-/ >> >> Cheers, >> juan pablo >> >> >> El jue, 13 nov 2025, 22:30, Alex O'Ree <[email protected]> escribió: >> >> > JSPWIKI-1220 is next to merge which has today's change log and version >> > bump. >> > >> > The change log and version bump thing is a pain to do for all these >> > branches as it causes constant merge conflicts. >> > >> > I'll see if i can fix jenkins >> > >> > On Thu, Nov 13, 2025 at 4:18 PM Juan Pablo Santos Rodríguez < >> > [email protected]> wrote: >> > >> > > Hi! >> > > >> > > Glad to see that influx of PRs coming! :-) I'll try to review them as >> > soon >> > > as I'm able. >> > > >> > > As for the PRs, I'd just ask to increase the version at Release.java + >> > add >> > > the appropiate entry at Changelog.md for each "unit of work" (term a >> bit >> > > vague on purpose). That allows easier following for what's in for each >> > > "unit of work" on a glance rather than going through the commit list, >> and >> > > also is used to generate the changelog on the static site. >> > > >> > > BTW, the jspwiki-site build is failing ATM, I think it's because it >> uses >> > > JDK-11, but should use JDK-17 instead, if you won't mind, It should be >> > > fixable pretty easily. >> > > >> > > Regarding changing behaviour, if it's noted on the Changelog.md we >> could >> > > add a note later at the NewIn pages. If the change is big, then it >> should >> > > be discussed on the MLs, but that's business as usual. We have some IT >> > > tests that can be used that can validate at least the basic behaviour. >> > > Currently they're using Selenide (a Selenium wrapper), and there're >> also >> > > some really old selenium html files, that I've meant to migrate to >> > Selenide >> > > at some point, but there they are :-/ >> > > >> > > And of course, being "the new guy" means "a fresh pair of eyes" so >> please >> > > anything that you see weird, just ask, there's a chance it's just >> weird >> > but >> > > we've become accustomed to. >> > > >> > > Kind regards, >> > > juan pablo >> > > >> > > El jue, 13 nov 2025, 16:13, Alex O'Ree <[email protected]> >> escribió: >> > > >> > > > Greetings >> > > > >> > > > As you all have probably noticed, I've been busy making changes and >> > > fixing >> > > > bugs with JSPWiki. I've merged a bunch of branches already that are >> low >> > > > risk type of JIRAs. >> > > > >> > > > I've also implemented a number of new features that may potentially >> > > change >> > > > some APIs and cause some heartburn. I'd like to request that as you >> all >> > > > have free time, please head over to the PR section on github to >> check >> > out >> > > > the chaos I've created, tell me what I did wrong and hopefully a >> way to >> > > > improve upon them. >> > > > >> > > > https://github.com/apache/jspwiki/pulls >> > > > >> > > > As the new guy on the project, it's always a challenge to understand >> > what >> > > > the "right" way is to add new features to an existing, well >> established >> > > > project. Patterns and practices developed over years by multiple >> > > > contributors are rarely documented and are seldomly obvious. So >> light >> > the >> > > > torches and get the pick axes. I'm ready when you are. I'll do my >> best >> > to >> > > > make it "right", whatever that ends up being. >> > > > >> > > > Alex >> > > > >> > > >> > >> >
