Jan there is a solution to the issues you are worried about and it's called npm.
npm gives you the option but not the obligation to load multiple versions of the same dependency. That's one of the main reasons that I would recommend it for large, complex applications. On Wednesday, February 26, 2014 6:07:50 PM UTC, Jan Miksovsky 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/b08d3abc-92bb-46de-b125-0df1e6c7dc11%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
