On Thu, Dec 11, 2025 at 8:04 PM Daniel Sahlberg <[email protected]> wrote:
> Den tors 11 dec. 2025 kl 17:39 skrev Evgeny Kotkov via dev < > [email protected]>: > >> Evgeny Kotkov <[email protected]> writes: >> >> > If there are no objections, I plan to start moving things forward >> shortly. >> > Hopefully, we can get 1.15 out within the next two to three months. >> >> I have checked the current state of trunk, and I believe we're in good >> shape. >> Specifically, there appear to be no loose ends or incomplete new features >> and the last potentially destabilizing change (r1927953) occurred four >> months ago. >> >> From the RM perspective, I propose we proceed with creating the 1.15.x >> branch >> shortly, and defer any other outstanding items to 1.16.x. This should >> allow >> us to keep our focus and attention on various tasks required for 1.15.0. >> >> Assuming no objections, I can plan to complete the remaining preparatory >> steps and create the 1.15.x branch on Monday, December 15th. >> >> >> Below is a detailed status check based on our documented steps [1] for >> creating a new minor release branch: >> >> 🗹 Review the Roadmap. Should any of the outstanding items be addressed >> before branching? >> >> Comment: Personally, I do not think we should be starting any additional >> features for 1.15 at this stage. >> > > How about Timofei's UTF-8-branch? The branch readme indicates that all > commands are ready. Can we get this merged before branching? > I think our current first priority should be to focus on getting 1.15 out. Of course it would've been great to also include UTF-8 cmdline work, but since we have so many changes to release already, I feel like we could leave it for future. Considering the fact that we might also expect 1.16 soon after, there is no need to force it into 1.15. Anyways, the branch is almost ready. According to my TODO list we only need to fix the failing test. I even have a draft of a merge log-message. To fix deprecation warnings which are currently produced when compiling trunk, is another issue. I was originally thinking that since the branch bumps this function, we were fine. However, now it's a bit of an awkward situation because now we need to introduce a new compatibility wrapper for this function and then bump it in the UTF8 cmdline branch once again. For a bit of context, this function was marked as SVN_DEPRECATED attribute back in r872846 alongside a bunch of other functions. I may guess that all functions without explicit usages in the codebase were GREPed and marked with this keyword even though there was a function with exactly the same behaviour, but in the private API. -- Timofei Zhakov
