Re: Dropping vcproj [Was: Subversion 1.15.0-rc3 up for testing/signing]

Den lör 18 juli 2026 kl 15:16 skrev Branko Čibej <[email protected]>:

> On 18. 7. 2026 14:26, Timofei Zhakov wrote:
>
> On Thu, Jul 16, 2026 at 11:22 PM Daniel Sahlberg <
> [email protected]> wrote:
>
>> Den ons 15 juli 2026 kl 14:58 skrev Ivan Zhakov <[email protected]>:
>> ...
>>
>>>
>>> Also I think we should drop support vcxproj support in the long term.
>>>
>>
>> Agree. I would support a decision to announce it as deprecated and
>> planned for removal in a subsequent release. The reason for deprecating and
>> not just removing it is that it is currently a functional build system and
>> it might disturb downstream users if we just remove it.
>>
>> Can we reach consensus on a decision already before the release of 1.15?
>>
>>
> +1, I think it's time for it to go.
>
> I'm on SIGKILL rather than SIGTERM squad :)
>
> As Ivan summarised the reasons, plus many small notices on-list throughout
> the days, I don't have much to add. It becomes a debt to maintain. I don't
> see how vcxproj support is used in the long run.
>
> Also a few points from Brane's reply (quoting is messed up, sorry):
>
> > We are maintaining three different build systems, there's no need to
> embellish. We maintained two until CMake came along. If we stretch the
> definition of "similarity" to make the CMake build similar to the Autoconf
> build, then I'll have to double-check we're not implementing Subversion in
> Go or some such. :)
>
> Ye, that is the idea that cmake is more like autoconf, aiming to repeat it
> as much as possible. I see nothing wrong with it.
>
> > That's a red herring. Nothing in the vcxproj build is blocking anything
> in CMake land. They are, as you note yourself, completely different build
> systems.
>
> But maintaining both has its costs. Not saying we can't do that but I'd
> rather spend time doing something useful than fixing a build system that we
> don't want people to use in the future anyway.
>
>
>
> I was being pedantic. The argument was "removing this ... allows that"
> without mentioning effort conflicts. Of which there are few, as far as I'm
> aware, very little effort has been spent on maintaining the vcxproj build.
> That no-one has *wanted* to maintain it is neither here nor there. :)
>
>  If we're debating, let's be precise. It's more honest to say, "let's
> remove this because I don't like it" than invoking a non-existent conflict.
>
> I mean, I'd love to remove all this Windows support mess, I don't like it
> at all ... even remove Windows from this reality altogether. One can dream,
> right?
>
> -- Brane
>
>
I see no voices saying we should keep vcproj. Some have been suggesting a
more agressive removal strategy and some a lighter touch. I believe have
consensus on the removal and I think declaring deprecation now should be a
nice middle road. I've tried to write up something in the draft release
notes (and Nathan has checked my language - thanks!).

Cheers,
Daniel