@grace Mid-November looks reasonable - provides buffer time as the process often takes longer than expected. We’d want to avoid December when folks start heading out for the holidays.
I think rather than try to focus on a due-date for this release, we should identify the features that we want to see in this release and start preparing the release once those features are available. I’d rather we don’t release 3.6.0 this year, but definitely have the printing stuff in it.
I get your point @ibacher - yet IIUC, we seem to have more than enough suggested & requested for the next release (I’ve tried to keep the draft release notes up to date with the suggestions/requests, as shown under “Key Features” here: https://openmrs.atlassian.net/wiki/spaces/docs/pages/557645825 ). Even without the printing (though that should get in if possible). I’d worry that if we don’t release before Dec, then the next release will be Feb/March, and will feel quite overwhelming since that will end up having 5+ months of changes in it (since last release will have been Sept).
I really am more concerned about ensuring we deliver features than anything else; 3.5.0 (the last release) felt particularly thin. I’m also think we’ve got a fair bit to do just to hammer out the main things I’d like to see for 3.6.0 (the patientdocuments module, 2.8.0 support including updating modules to use the StorageService, and fixing the demo metadata so that it correctly loads) by mid-November. Since, historically, it’s taken 3-4 RCs to get everything squared away, aiming to release in easily December more than likely means that the release will be ready around Christmas. So an early 2026 release feels a bit more pragmatic.
(I’m not saying there aren’t issues with the release process itself; there are always improvements to make and there is a reason i added thinking about the frontend release process to the hackathon).
To say more on the metadata thing: currently the OCL module isn’t properly processing the Basic Lab export or the content in the Basic Lab export doesn’t match what OCL claims it should; I don’t think the “Address Hierarchy” stuff has ever properly loaded and there are a few dozen Iniz errors in the RefApp start-up log that we should track down and fix.