On Sun, Dec 14, 2025 at 4:26 PM Timofei Zhakov <[email protected]> wrote:
> On Fri, Dec 12, 2025 at 11:57 PM Branko Čibej <[email protected]> wrote: > >> On 12. 12. 25 17:21, Timofei Zhakov wrote: >> >> 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. >> >> >> >> We're allowed to use our own deprecated functions and to not provide a >> non-deprecated version. They won't be removed until 2.0, so ... never. It's >> inconsistent, but [1]. >> >> >> 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 >> >> >> [1] >> https://en.wikipedia.org/wiki/Wikipedia:Emerson_and_Wilde_on_consistency >> >> > Hi all, > > I went ahead and decided to undeprecate the function in r1930574. > > Also, after some API review, I'm considering that the XML parser stream > should not be included in the 1.15, because there are no real usages up > till this point -- only the test-suite. It includes the addition of the > svn_xml_make_parse_stream() function and implementation helpers. > > If there are no objections, I'm planning to remove it as soon as the > stable branch creation is initiated. I suggest we leave it in the trunk > (xpatch is coming back!). > Hi, Once the 1.15 branch is created, we don't make changes to it except by voting in STATUS (except certain files that the RM will need to edit). Do you wish to remove the XML parser streams from 1.15 because of concern that the API/ABI may need to change? If so, would it be good enough to make the function(s) private (to avoid API/ABI compatibility guarantees) until you're ready to work on it again? That's it from me (for now). > > -- > Timofei Zhakov > Thanks, Nathan >
