On Tue, Nov 13, 2012 at 8:05 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote: > On 2012-11-12 6:01 AM, Henri Sivonen wrote: >> >> On Fri, Nov 9, 2012 at 10:32 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> >> wrote: >>> >>> Sort of. Well, from time to time we add a new DOM API which breaks a >>> website because they expect that name to be available as an expando >>> property >>> or something. >> >> Prefixing doesn't fix this problem. It only defers it, which (I think) >> is worse than finding incompatibilities early on and changing the >> names in the spec not to collide with what’s already used out there. > > I agree. Prefixing in practice is really just a way to make us feel better > about breaking something which we have shipped before, and that's bad for > web developers. But this is sort of an orthogonal discussion.
I think it isn’t orthogonal. I think having a way that makes us feel better about breaking stuff is something we shouldn’t have. I expect we’d make better decisions about breakage if we didn’t have an excuse that allows us to delude ourselves about the fact that breakage is being caused. >>> But that's not really important, I'm mostly concerned about >>> the stuff that we will ship in the future. The specific thing that I'm >>> worried about is Web Audio which is a huge spec and we may not be able to >>> implement all of it for quite a while for a variety of reasons, and it >>> might >>> be difficult to decide whether implementing more of it will break >>> existing >>> users, because, among other things, the spec is also changing. >> >> >> If a spec is actively changing in breaking ways, we shouldn’t ship an >> implementation to the release channel. OTOH, once an implementation >> has been shipped to the release channel and Web content depends on in, >> a reasonable spec editor won’t make breaking changes anymore. >> >> So if we agree that breaking changes are still necessary, we shouldn’t >> ship. If we think we need to ship, we need to tell the spec editor not >> to make breaking changes anymore. > > I'm not sure if that call can be made easily in all cases. There might be > parts of a given spec that we don't want to implement because they are bad > ideas, and while we try to fix them in the spec, doing so is not always > possible. Our position on such types of issues might change because web > developers may start depending on those features to an extent where we have > to implement them, and I'm afraid that with the policy you're proposing, > such cases may prevent us from shipping a feature to the release channel > unprefixed for an extended period of time. On Tue, Nov 13, 2012 at 10:14 PM, Randell Jesup <rjesup.n...@jesup.org> wrote: > Henri Sivonen <hsivo...@iki.fi> writes: >> Either way, a moz prefix won’t help. (It’s worthless as a “this will >> break” signal.) > > Agreed. It seems to me that we won't get agreement on policy about not shipping experimental features on the release channel. However, it seems to me that we could be able to agree not to ship moz-prefixed APIs on the release channel. So I adjust my policy proposal to: Therefore, I propose that we adopt the following policy: 1) APIs that are shipped on the release channel shall be shipped without a prefix. 2) If we ship APIs that don't have specs already, we'll write specs. I think a policy not to ship moz-prefixed APIs on the release channel would give enough flexibility to ship experimental features (without prefix) when market pressure so requires but would generally have positive consequences that would lead to less breakage for features that have reached the release channel. In the case of features that Gecko developers know to be unbaked without compelling market pressure to ship them in an unbaked state, I would expect this policy to have the consequence of not shipping such unbaked features on the release channel. (For this to be easy to accomplish, there should probably be a C preprocessor define that is different for Release (and maybe Beta) compared to Aurora, Nightly and self-built. In the case of features that are technically in good shape but just haven't had a standards setting group put their mark on them, I think this would have the positive effect of discouraging bikeshedding. For example, if we had shipped the full-screen API without prefix, I expect we could have avoided the total bikeshed of changing the case of the letter ‘S’ in “fullScreen”. (It’s so confusing that even MDN contradicts itself. I’ll fix after sending this email.) In the case of features where we don't know if the general design will be accepted as a cross-browser standard, shipping without prefix makes things better in the case our design gets accepted. With prefixes, we get breakage either way, so with prefixes we are always betting wrong. If our design doesn't get accepted, the standard can simply choose a differently-named API entry point. After all, the space of possible identifiers is countably infinite. In case of features like WebRTC where it's almost certain that breakage will occur, if we ship without prefix, we’ll be no worse off than shipping with prefix. Breakage occurs either way and experience shows that a prefix is worthless as a signal of API stability. So even in cases like WebRTC, it makes sense to bet for the case where breakage doesn't need to occur (i.e. the spec doesn’t end up changing after all). On Wed, Nov 14, 2012 at 8:53 PM, Mounir Lamouri <mou...@lamouri.fr> wrote: > On 06/11/12 13:31, Henri Sivonen wrote: >> Therefore, I propose that we adopt the following policy: >> 1) APIs that are not ready for use by Web developers shall not be >> shipped on the release channel (unless preffed off). > > For that, we will need some tools to know if we are building for Release > (and let say Beta) where the feature should be hidden by default, with > opposition to Aurora, Nightly or custom builds where the feature should > be enabled by default. So let’s get a C preprocessor define for that. It shouldn’t be a big deal to conjure a suitable one into existence. > Also, how would that work for things that doesn't have > Nightly/Aurora/Beta/Release channels? Surely Firefox OS has *some* distinction between release builds and development builds? -- 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
