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
