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.) > 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. > 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. > 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. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
