On 2012-11-27 3:49 AM, Henri Sivonen wrote:
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.
I totally agree. But note that this is basically rephrasing "prefixing
sucks" in a better way. :-)
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.
Where do partial implementations of specs fall here? Can we ship
something unprefixed without implementing the full spec?
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.
And what will happen to the original name that we've shipped? Would we
remove support for it at some point?
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.
Hmm, Web IDL bindings already support exposing names hidden behind a
pref, so we can technically do without the C preprocessor macro that
you're proposing, at least for the stuff that we can use Web IDL
bindings for (and that's what everybody is using for the new APIs,
right? ;-)
I think we should prefer prefs over build-time flags, since they always
have the chance of surprising us when we uplift something from Beta to
Release.
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
