Go 1.3 will remove Windows 2000 support

[Russ Cox]

CL 74790043 - which requires Windows XP - does fix the spurious problems we've been seeing on the windows-386 builder, and it cleans up the runtime (7 #ifdefs removed!), and the discussion on golang-nuts raised no compelling reason we need to keep Windows 2000 support, so Go 1.3 will include this CL and remove support for Windows 2000.

I do realize that a few people spoke up saying that they use or prefer Windows 2000, but we have to draw a line somewhere, there are very few potential users on that side of the line, and the available Windows 2000 expertise we developers can draw on is near zero and shrinking. The simplifications and fixes made possible in the runtime by assuming Windows XP outweigh the few potential uses. Go 1.2.1 will of course continue to run as well as it does today (I think it has the same latent bugs but if you're not seeing them, you probably won't start seeing them.)

The discussion also raised a comparison with Plan 9, which I think is an interesting one. When there are mysterious problems on Plan 9, the source code is available for consultation, we have Plan 9 experts available to answer questions, and, in at least one instance, Plan 9 has been changed to aid Go's implementation. None of this is true of Windows 2000.

I know some people have volunteered to run a Windows 2000 builder and to keep maintaining the code. If you are serious about that, I suggest that you create a public hg clone with the Windows 2000 changes and point people at that. However, if you are thinking about doing this, I would caution that I think the problem is harder than you might realize and the payoff smaller. There may be more impactful ways to spend your time.

Thanks.

Russ

[Dave Cheney]

Sounds good to me.

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[brainman]

SGTM

Alex

[minux]

If we maintain a official windows-2000 port, we still need a builder to keep us honest.

Should we maintain our own builder dashboard? Or could the official dashboard provide

a separate instance for community supported ports (forks)?

For example, for future Go ports, the developers could first add a builder to that dashboard

and watch the builder failures and got notified. (I think that kind of dashboard should only

send broken mail to the owner of builder or port).

I haven't yet finished the community/unsupported dashboard idea, but I think it's generally

useful. (the basic idea is that every builder runs on its own repository, and dashboard notify

them about every official tree commits, and they will use some user defined mechanism to

automatically merge the changes and then run all.bash or even just make.bash)

This could be a great help to developers of new Go ports (or this case, maintainers of deprecated

ports).

At least for me, I don't want the burden of maintaining my own builder dashboard, and also

a separate dashboard for each fork just doesn't make sense. So at the very least, the community

will need to maintain the dashboard.

[Russ Cox]

Please don't bother with a Windows 2000 port. It is just not worth the effort. There are so many more significant things you could spend your time on.

Russ