> The most important changes on the user level are the long path name > support including UTF-8 character support, as well as IPv6. Other > changes are also important, but these two will likely have the most > impact. I'd like to ask you to keep an eye especially on them when > building and testing.
OK, a few questions and comments: (1) Do all packages that include compiled code need to be rebuilt for Cygwin 1.7? IOW, is ABI compatibility broken from 1.5? Also, I presume that there would be no need to rebuild any packages that don't include compiled code, e.g. packages that depend only on Perl or Python. (2) If I understand right, the implication here seems to be that although Cygwin 1.7 will support the above features, it's going to be up to us package maintainers to ensure, or at least just test, that our packages support them too. But, there seems to be no requirement about that. That is, we could just dump our packages as they are into Cygwin 1.7, and not test them for any of the new supported features, assuming our consciences allow this. Correct? (3) For packages that have been tested, are we going to have a standard and/or common location or format in which to put our "tested against Cygwin 1.7/tested for long file name/UTF-8/IPv6/etc. support" results? Or just note the results or not in our README.Cygwin files? The latter seems fine to me, I'm just wondering. (4) It seems that it might be useful to develop standard unit tests for some of these features. Long file name support is simple enough-- we just have to create some path names longer than 260 characters, and try feeding them to our applications. But for UTF-8 and IPv6 support, it could take each of us a lot of time to work out tests on our own. Or at least, it would take me a while since I'm mostly ignorant of them... A standard, documented approach would sure help me, and maybe other packagers too. I freely admit though that I am not volunteering to do this. Thanks, Andrew.