[feature] Drop support for Win32 platforms older than Windows Vista

[Grinnz]

Perl's Win32 platform support is currently specified back to Windows 2000 and XP, however these two platforms in particular (as well as Windows Server 2003) are increasingly problematic to support. They are long out of support and have, by all indications, near zero usage share. Thus, I believe the risk-benefit balance of removing support for 2000, XP, and Server 2003 is clear enough for quick consensus.

Please feel free to describe or link issues that would be easier to solve or obsoleted without the need to support these platforms.

Recent p5p discussion

[tonycoz]

The new win32 symlink() code and tests could be simplified.

[yuki-kimoto]

The advantage of being able to easily write symlink() is good.

Windows 7 still has a lot of shares, so I would like it to be supported even if there is no Microsoft official support.

Windows XP and Vista share is small (about 1%).

Personally, I think it's okay to remove support if Perl's porting is simplified.

[wchristian]

We had a discussion about this before.

Before you can "drop support" for something, we must first actually define what "support" means and define it, as well as policies and guidelines for dropping support, and document them.

Right now the state of all of the above is, simply, complete chaos and undefinedness.

Please, do at the very least demonstrate that you have read the first post here and the linked documentation to learn that you are asking here for something that doesn't even exist, neither in the positive nor negative sense:

#18243 (comment)

[Grinnz]

Drop support in this case simply means allowing development and simplification of features that break functionality on these platforms.

[wchristian]

There's nothing forbidding it in the first place. There is no support policy, list or guarantee in the documentation.

[Grinnz]

That is not true in practice, as I have observed core committers repeatedly take extra effort to ensure support back to windows 2000.

[Grinnz]

(Thank you for linking that issue as I had forgotten about that discussion)

[Grinnz]

The definitions of supported platforms and making consistent the appearance and practical support is a task that needs some agreement and authority. The goal of this issue/discussion is simply to achieve consensus that nobody needs to work to support these specific platforms anymore, because we currently have not expressed that and they are hindering progress on Windows issues that already have precious few contributors capable of tackling them.

[wchristian]

That is not true in practice, as I have observed core committers repeatedly take extra effort to ensure support back to windows 2000.

Right, which is also problematic in its own way. If demands are made on people as something that aren't simply requests or self motivation, then those should be grounded in documentation.

(Thank you for linking that issue as I had forgotten about that discussion)

Cheers. :)

The goal of this issue/discussion is simply to achieve consensus that nobody needs to work to support these specific platforms anymore, because we currently have not expressed that and they are hindering progress on Windows issues that already have precious few contributors capable of tackling them.

I'd prefer to see it the other way around, for a simple reason:

Explicitly declaring "x is now deprecated" invites people to become zealous and start cutting out things, resulting in reduced functionality, without also creating new features.

I'd rather see people declare "i want to do this, and to achieve that, i'd need to break this".

[wchristian]

(There's also the side point of this, as far as i can tell, being the only declaration of something as deprecated without that being done in direct connection with "i want to implement this"; and i'd be unhappy to see this kind of special treatment of one thing, when no such special treatment is needed at all.)

[Grinnz]

I'd rather see people declare "i want to do this, and to achieve that, i'd need to break this".

I wish to encourage that in this discussion as well.

[wchristian]

In that case, maybe it could be made as a round call for intent to work on windows features, explaining that there is no support policy, and inviting people to state what they fear might hinder them in doing so, to gauge if said things would actually cause opposition?

[khwilliamson]

@xenu informs me that names for locales didn't really come along until Vista; this means that locale support is pretty crippled on earlier versions, and I think it's not worth our precious effort trying to do any support form them

[yuki-kimoto]

@wchristian

Before you can "drop support" for something, we must first actually define what "support" means and define it, as well as policies and guidelines for dropping support, and document them.

Clearly defined things is beneficial in some case.

On the other hand, Practical things is good in many cases.

Isn't the point that core developers want to stop old windows support because they want to make Windows porting code more manageable and simple?

so, core team think they want to get consensus.

[wchristian]

Isn't the point that core developers want to stop old windows support because they want to make Windows porting code more manageable and simple?

Please actually read the linked ticket and previous discussion to learn how the point is that there is no porting policy in the first place and that asking to "stop support" is asking everyone to believe in something imagined.

[yuki-kimoto]

@wchristian

I can agree that there is no clear porting policy written.

"stop support" message maybe means "stopping newer Perl to run old windows".

[wchristian]

@yuki-kimoto imo, the best faith reading of the material i can offer is:

"no guarantee of support is made, and if someone wants to implement a feature that would break something, it would be polite of them to ask beforehand, and the final call is with the committer and the pumpkings at their own discretion"

and imo, in lieu of actual policy i believe that should be retained, instead of engaging in special treatment for windows that would not be done for any other os

[rjbs]

I think it seems useful to have a list of platforms such that:

• we consider not building on platform X to be a bug, to be fixed before a stable release
• we consider not building on platform Y to be expected, and not a reason to add code complexity

Some platforms will clearly be the first kind and some the second kind. Everything else is unknown until classified, but probably the answer can often be "look, if it worked yesterday and the thing that broke it isn't worth much, why did we break it?" My guess it that there are versions of Windows we would like to categorize as Y. I will raise this on the list soon.

[yuki-kimoto]

If there are the list, I think it is kind.

[Leont]

I think it seems useful to have a list of platforms such that:

* we consider not building on platform X to be a bug, to be fixed before a stable release

* we consider not building on platform Y to be expected, and not a reason to add code complexity

Some platforms will clearly be the first kind and some the second kind. Everything else is unknown until classified, but probably the answer can often be "look, if it worked yesterday and the thing that broke it isn't worth much, why did we break it?" My guess it that there are versions of Windows we would like to categorize as Y. I will raise this on the list soon.

I think that defining tiers may be helpful for that.

[khwilliamson]

Can we get some progress on this?