>On Sat, Dec 8, 2012 at 5:24 PM, Randell Jesup <rjesup.n...@jesup.org> wrote: >> tl;dr - prefixing is bad. It's not good even before Release. API >> version suffixing may be better. > >Are you OK with the latest policy proposal I made or do you intend to >make a counter-proposal with suffixing? > >Latest for reference: > 1) Excluding WebGL and WebRTC APIs, new APIs that are shipped on the >release channel shall be shipped without a prefix. > 2) If APIs that don’t already have specs are shipped, we’ll get specs written. > >(This policy implies nothing about what exactly WebRTC or WebGL do. >They are simply outside the scope of the proposed policy.)
I'm ok with it, but I think it may be insufficient to avoid problems. One could argue if we're going to try to push everyone to move off the current prefixing, let's do it once. We're not likely to try again soon, let alone succeed. Is it better than today? Yes, arguably. Does it solve the fundamental problems? Only partly, and really only if everyone follows suit. Are Google, MS and Apple (and Opera) on-board with this? >> Sure, if when standardized people add another parameter, you can change >> the feature from Foo to Foo2 (or Bar, or Qwerty). > >Better yet, adding more arguments to a method does not require >changing its name at all. Quite true (and I mentioned elsewhere); I was writing quickly. Please re-read as "some API change that's not backwards compatible". >> one can argue that ALL APIs should >> have version suffixes > >Even if WebRTC ends up using version suffixes, let’s not do that for >APIs in general. Experience suggests that it has been possible to >introduce APIs (e.g. APIs introduced by IE of old, canvas 2D or APIs >introduced by “HTML5”) without either prefixing or suffixing, so >making suffixing a rule seems like an overkill. I think in the usual >case (i.e. the non-WebRTC, non-WebGL case), it would make sense to see >how well we’ll do without either prefixes or suffixes. If we end up >doing fine, there is no need to add complexity. > >Also, version suffixes can re-introduce the problem that, like vendor >prefixes, they might make us think it’s more OK to still bikeshed >things and introduce just one more version. Both reasonable arguments. Versioning might be best reserved for more-complex-than-average APIs and ones where people want to do cross-browser experimentation (pre-release). The second argument might be minimized or avoided by not shipping suffixed APIs for the simpler ones. Though I'm unsure how large a problem this would be, compared to the current issues with prefixing. >> Perhaps in some >> case it will make sense to add a Foo2 and support both, either forever >> or for a while. But that's really a separate, though related, question. > >I don’t think it’s a separate question. With version suffixing, there >is a very real risk that removing old versions will break too much >content and so old versions stick around forever. In that case, the >same kind of considerations as those stated in >http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.html and >http://robert.ocallahan.org/2008/01/http-equiv_22.html apply. Yes. It's a classic "stick with something forever" or "support the old thing (virtually) forever" or "break the old thing (now or sometime 'soon')". This certainly has minuses, but never improving does too. And introducing it under a totally different name (instead of Foo2) doesn't change anything. -- Randell Jesup, Mozilla Corp remove ".news" for personal email _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
