>> Polymer ...[is] big, for one thing, and patches the browser in all sorts of ways
This is `platform.js` you are talking about which must be considered independently from Polymer itself. >> And all this complexity You provided a lot of commentary there, but nothing that struck me as novel from a versioning perspective. As long as there have been libraries, this has been an issue. >> where the project owner can follow the dependency chain The project owner need not do that. Component A may involve a 'bushy tree' of dependencies, but they all flow from Component A. If Component A is a compatible version, that's all you need to know. Scott On Wed, Feb 26, 2014 at 10:07 AM, Jan Miksovsky <[email protected]> wrote: > Scott: Thanks for sharing Polymer's perspective on this. I'm still unsure > where that leaves businesses that want to include a variety components > which aren't all developed in lock-step. > > Let's stipulate that Polymer is a special case in a number of ways. It's > big, for one thing, and patches the browser in all sorts of ways that might > make loading multiple versions challenging. Polymer's also got a sizable > full-time team behind it that can maintain the project in perpetuity. Let's > further stipulate that Polymer has a focused role that, once finished, will > not change much in the future — and, hence, won't be subject to many > breaking changes. Finally, Polymer has a non-trivial set of interrelated > components whose deployments are closely coordinated by the team. > > So let's set all that aside and consider the question: what about all the > other components? Suppose components X and Y depend on some useful building > block Z. Perhaps X and Z are actively maintained by teams, but Y is an > evening hobby project for a single person. The day Z includes a breaking > change that X wants to track — but which Y can't track yet (or ever) — the > project including both X and Y is horked, no? > > We could say that tracking all this is the responsibility of the project > owner. If the makers of X, Y, and Z are very careful about versioning, > perhaps the project owner can follow along closely enough that to see that > they can't use the latest X yet, because that depends on the latest Z, and > Y's still requires an older, incompatible Z. If the project owner is lucky, > Y might update quickly enough. Or maybe the author of Y is off doing other > things. Y still works on its own, but in practice it's useless because its > dependency on an old Z makes Y unworkable in apps that include the latest > and greatest X. > > And all this complexity is in a tiny, toy case where the project owner can > follow the dependency chain without too much trouble and work out which > versions they can use. But I already have components with small, bushy > trees of dependencies several levels deep. I think it'll be too much to > expect someone to carefully walk through all the dependencies for every > component their project includes to work out potential incompatibilities. > That is, the "high-granularity, high-reuse model" creates enormous work. > Even if Polymer itself closely manages backward compatibility and > versioning, it's unlikely every component vendor will proceed as carefully. > > I'm just expressing a concern that dependency management feels like an > underexamined (or under-documented?) aspect of the component ecosystem. In > practical terms, I'm concerned this will limit the ability of businesses to > freely include components from different vendors who aren't closely > coordinating their actions. > > On Tuesday, February 25, 2014 7:47:23 PM UTC-8, Scott Miles wrote: > >> The notion that one cannot always use something that requires version X >> of a thing with version Y of that thing is inherent in the concept of >> versioning. >> >> Polymer is advocating a high-granularity, high-reuse model. Any such >> model is particularly susceptible to version pain, however Polymer is >> really not breaking new ground here. >> >> Once we reach a stable version number, then, like many projects, we will >> document a contract about restricting API-breaking changes to major version >> number increments, or something along those lines. At that point, packages >> will need to use bower ~ syntax to select an appropriate version range. >> >> In my opinion, using multiple versions of any library in a single project >> is a dramatically bad idea. I also suspect that, once we achieve stable, >> Polymer will not need to evolve nearly as rapidly or as often as JQuery. >> Having said that, there is nothing we are doing to block eventual support >> for multiple versions in one project if it turns out I'm wrong. >> >> >> On Tue, Feb 25, 2014 at 5:50 PM, Jan Miksovsky <[email protected]> wrote: >> >>> I was just trying to use a component whose bower.json turned out to >>> declare a dependency for "polymer": "~0.1.4", with a hard-coded version >>> number. The rest of my project declares a similar dependency for "polymer": >>> "Polymer/polymer#master" to get the latest version. When doing a Bower >>> update, Bower indicated that I needed to resolve this conflict by picking >>> which version of Polymer I wanted for the component called "polymer". Urk. >>> While it's easy enough for me to tell Bower which version of Polymer to >>> use, I now have no guarantee that the component requesting a specific >>> version is going to run. (In fact, it doesn't.) >>> >>> This seems like a dependency management problem of the first order. Is >>> there some plan for how Polymer projects will eventually be able to include >>> components that depend on different versions of Polymer? >>> >>> Part of this problem appears to be a Bower issue (not Polymer): as far >>> as I can tell, the installed set of components ends up as a flat folder >>> structure within the /components folder. Even if this is a Bower problem, >>> though, Polymer's de facto standardization on Bower makes this a >>> potentially limiting issue for the Polymer ecosystem. >>> >>> A separable part of the problem is the need to load multiple versions of >>> Polymer simultaneously. Has that been ruled out? I recall that jQuery >>> ultimately had to concede that, in practice, one couldn't always depend on >>> every part of an app and every widget being constantly maintained to run >>> with the very latest version of jQuery, and had to come up with a strategy >>> supporting multiple versions running on the same page. >>> >>> 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/33815a22-dedf-4067-8d6f-77a814ad0224% >>> 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/712b5667-05d2-4adb-9fcb-b50e7cf9cdeb%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/CAHbmOLb31QZwdAQkdVM0sa2RmCAfGPYB7GzPwoFTSkhnQ4qBrg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
