That said, is there a roadmap for what the future Pike 7.6 will be? I.e any plans, ideas, TODO's for Pike 7.5 before the next stable branch?
/ David Hedbor
Previous text:
2003-01-06 22:58: Subject: Inconsistency.
Ok, is_file was a mistake. The point is still there - there is no reason for them to have different naming. I'm sure there's other examples too though.
In either case, I don't like the idea of a silent fork to fix these issues to later release a "new" Pike. Rather I'd like to see a Pike 8 or what not which might not necessarily be backwards compatible - it's nothing wrong with that per se - major version number == possibly incompatible API with previous versions.
Iff incompatible changes were well documented I think it'd be great in the long run (note, this isn't so different from the stronger type checking and disallowing of equally named local variables - that change broke A LOT of code (just about any larger piece of Pike code I've used has at least one issue like this).
So my vote is that pike 7.5 (ir 7.7) will become Pike 8 where inconsistencies like this can be fixed and documented. Also it should probably include a lot of cleaning up (i.e modules using old module API's updated to use new ones, or even the cmod API and other such things (removing the 'spider' module is something that comes to mind too :-)).
/ David Hedbor