I'm not in favor of that. First, the major version change is not appropriate. Second, I strongly recommend not using a customized polyglot. Doing so will cause users issues when they try to use versions they find elsewhere, particularly if they can't find compatible ones anywhere else. If UCI support is that important, integrate it into winboard instead. I'm all in favor of making the two projects compatible with each other, but making a unique one for a winboard release seems very bad.
The problem is that almost all Polyglot versions that are around do not support the extensions of WB protocol offered by 4.4.0. It is unavoidable there will be user issues when they use such some versions. The version now supplied by Debian and Ubuntu is as obsolete as WinBoard 4.2.7. If WinBoard protocol is extended, the extensions wil not be effective for UCI engines unless there will be a new Polyglot implementing those exensions. I don't see how this could be avoided. Why would we want to intentionally ship them a Polyglot version that breaks part of the functionality of WinBoard? I don't see this as a matter of customizing. This Polyglot 2.0 (or whatever we would call it, that is really a separate, not so important issue) is a universally applicable Polyglot. It is not that I want to completely overhaul Polyglot for every future XBoard release we are going to do, and change things back and forth just because they are slightly more convenient for the particular XBoard version. But we are the ones responsible for developing WB protocol, and this unavoidably strongly affects Polyglot and any other adapter. So the future will see a gradual evolution of XBoard and Polyglot towards more powerful protocol, supplying the functionality modern Chess engines require. This Polyglot is merely one step along that line, not so much a customization. Of course we take etreme care in developing WB protocol in a way to provide backward compatibility. People used to working with older Polyglots and older GUIs in the old way (making polyglot.ini files etc.) would not notice any difference. Using old Polyglots with WB 4.4.0 will also not cause any issues when you don't use any of the new 4.4.0 features. E.g. the Engine #1 Settings dialog will simply remain empty when they use a Polyglot that does not support the WB option feature, or they will discover that the engine doesn't respond when they alter the hash size or number of CPUs in the GUI settings when they use a Polyglot that doesn't support the WB memory or core command. Or that they can alter the Engine Settings, but not save them, when they use a Polyglot that does not support a save option. Those kind of issues are unavoidable, but I don't see that as a reason to force them on everyone (by not including such new functionality in XBoard or shipping it with a Polyglot that breaks it).
