Alex: No flippancy heard on this end. You guys are doing great at encouraging and listening to community feedback.
I did want to follow up on Karl's point about the underlying web standards not being finished. Given Polymer's specific mission, I argue that it's in the industry's best interests for the completion state of those standards to *not* be a criteria for defining a Polymer 1.0 milestone. As I see it, Polymer's reason for existence is to provide a "browser of the future". I think I've heard Google use some characterization like that in the past. By adopting Polymer, I can pretend that all of my users are running a browser that doesn't exist yet. That virtual browser implements standards that are so new, no native implementation exists. And, in some cases, the standards themselves are still being revised and debated. The clever thing about the way Polymer's been defined is that it's a general purpose strategy for tackling any new polyfillable web technology, not just web components. The Pointer Events and Web Animations specs, for example, don't seem like critical pieces of an initial web components platform; they're simply new interesting web technologies that can be polyfilled the same way. It seems reasonable to conclude that more technologies will be proposed in the future which can be polyfilled that way too. That is, Polymer will *always* include features based on specs that have not yet closed. So I'm hoping an approach to versioning Polymer will accommodate the fact that it polyfills support for specs that have not yet closed. I think it's fine for there to be some Polymer version/spec matrix that indicates: "Polymer version *N* implements this set of specs, which are in the following states. Polymer *N*+1 implements this larger set of specs; some more are closed, the newest specs are still being worked on." I think there's another concession that needs to be made in defining versions for Polymer, which is limiting the guarantee of support for all future releases of the supported browsers. Often a 1.0+ version number implies indefinite customer support and bug fixing on behalf of the product creator. Given the nature of Polymer, I think such an expectation may be unfair. Suppose Polymer version 1.0 supports IE 10/11. Perhaps that version also works on IE 12, but let's imagine something lands in IE 13 that breaks Polymer 1.0 sites. I think it's acceptable to tell the Polymer 1.0 site that they need to upgrade the (two year-old) version of Polymer they're using. In other words, the support bargain between Polymer and the site using it could be: "If you want to exist in the world of auto-upgrade browsers, you yourself may occasionally need to upgrade your code." I think many small sites get written and then essentially left alone in perpetuity. If those sites want some guarantee they will work forever, they should wait for native implementations in all mainstream browsers. The browser manufacturers are generally very careful to avoid breaking old code. But the Polymer collective shouldn't be responsible for guaranteeing indefinite compatibility, because the ground can shift underneath them. If an organization is willing to invest in keeping their site up to date, then should feel comfortable using Polymer. The converse is also true: a organization that is unwilling to keep their site up to date should not use Polymer. In short, I'd be willing to accept a Polymer 1.0 that include provisos: "Polymer 1.0 includes support for the following standards as of this date, which are in the following stages of completion. Polymer 1.0 works on the following specific browser versions today. It is designed to work on those browsers as they auto-upgrade, but there exists a possibility that a future browser release may break code depending on Polymer 1.0, and require you to upgrade the version of Polymer you are using." On Friday, January 17, 2014 8:19:59 AM UTC-8, komoroske wrote: > > > > > On Thu, Jan 16, 2014 at 5:40 PM, Jan Miksovsky <[email protected]<javascript:> > > wrote: > >> Alex: I think it'd be great if Google could shoot for announcing that >>>> Polymer has reached 1.0 at Google I/O this year. Or, if not then, then to >>>> at least publish a roadmap to 1.0. That would be a huge help in promoting >>>> this to clients. >>>> >>> >>> I spend a lot of time thinking carefully about this kind of thing. :-) >>> >> >> No doubt! I'm only trying to help reinforce the message that outside >> parties are eager to promote web components and Polymer, and that a 1.0 >> version number will make that much easier. Thanks for listening! >> > > I just realized that my answer could have come across at flippant, which > was not my intention. One of the things that excites me most about Polymer > (and web components in general) is how folks from the community--like > you!--have taken such an active role in evangelizing to developers. As > always, your analysis and insight are very valuable. > >> Follow Polymer on Google+: plus.google.com/107187849809354688692 >> --- >> You received this message because you are subscribed to the Google Groups >> "Polymer" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/polymer-dev/7886e7bd-9990-4887-ae43-896edced9d7c%40googlegroups.com >> . >> >> For more options, visit https://groups.google.com/groups/opt_out. >> > > Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups "Polymer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/15033339-d8e0-40b6-8ee8-f9fdc749b867%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
