Den fre 12 dec. 2025 kl 16:23 skrev Timofei Zhakov <[email protected]>:
> 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. > Which function are you referring to? Cheers, Daniel
