3 ms·

I think it's done to decouple versions. Imagine component A updating its major, causing the whole suite to update its major. But that higher major might also ha

I think it's done to decouple versions. Imagine component A updating its major, causing the whole suite to update its major. But that higher major might also have newer versions of components B and C, but you don't want to upgrade your usage of these. There are cohesive component kits versioned as whole package, but I never liked that to be frank. I think this is good evolution, just messy because it's new. I'm sure better tooling will eventually emerge.

capableweb 6y ago
You know what you could also do? Don't break backwards compatibility. I know it sounds strange (if you're coming from modern JS development) but many ecosystems actually pull that off, like the entirety of Windows, or 99% of the ecosystem in Clojure/Script. Then if you have over the years collected a bunch of incompatible changes that you would like to do, you create a new library with a new name, and do all the changes there. Now you have the first library absolutely never breaking compatibility, and the second one for your "I absolutely must change the API interface here" changes. There are some good ideas around versioning here as well (by Rich Hickey): https://www.youtube.com/watch?v=oyLBGkS5ICk https://www.youtube.com/watch?v=oyLBGkS5ICk > just messy because it's new. I'm sure better tooling will eventually emerge. I don't understand this. Either a new solution is better and we try to use that, or the solution is worse and we should avoid it. If it's worse, why should we build better tooling when we can just use a good solution from the get-go?
- emteycz 6y ago
  > I don't understand this. Either a new solution is better and we try to use that From my perspective coming from my experience both as a component kit developer and an application developer using that kit, having one component per versioned package is good. That we live in a world where larger packages are prevalent and thus tooling forces a developer to duplicate configuration everywhere is an unfortunate coincidence that doesn't take away the benefits of separating the project into one versioned package per component. Also consider that it might not even be because of the development tooling, but rather VCS or CI/CD related.
jscholes 6y ago
> I think it's done to decouple versions. From the repo's README: > We have 16 open source custom elements: It's feasible that GitHub also have some components that are temporarily or permanently private. Having one repo per component may help to remove the need for that distinction among GitHub developers, who don't have to first check whether to import a component from a public or internal repo.
serverholic 6y ago
Having a consistent version number gives you some reassurance that your components are compatible with each other.

capableweb 6y ago

You know what you could also do? Don't break backwards compatibility. I know it sounds strange (if you're coming from modern JS development) but many ecosystems actually pull that off, like the entirety of Windows, or 99% of the ecosystem in Clojure/Script. Then if you have over the years collected a bunch of incompatible changes that you would like to do, you create a new library with a new name, and do all the changes there. Now you have the first library absolutely never breaking compatibility, and the second one for your "I absolutely must change the API interface here" changes. There are some good ideas around versioning here as well (by Rich Hickey): https://www.youtube.com/watch?v=oyLBGkS5ICk https://www.youtube.com/watch?v=oyLBGkS5ICk > just messy because it's new. I'm sure better tooling will eventually emerge. I don't understand this. Either a new solution is better and we try to use that, or the solution is worse and we should avoid it. If it's worse, why should we build better tooling when we can just use a good solution from the get-go?

emteycz 6y ago
> I don't understand this. Either a new solution is better and we try to use that From my perspective coming from my experience both as a component kit developer and an application developer using that kit, having one component per versioned package is good. That we live in a world where larger packages are prevalent and thus tooling forces a developer to duplicate configuration everywhere is an unfortunate coincidence that doesn't take away the benefits of separating the project into one versioned package per component. Also consider that it might not even be because of the development tooling, but rather VCS or CI/CD related.

jscholes 6y ago

> I think it's done to decouple versions. From the repo's README: > We have 16 open source custom elements: It's feasible that GitHub also have some components that are temporarily or permanently private. Having one repo per component may help to remove the need for that distinction among GitHub developers, who don't have to first check whether to import a component from a public or internal repo.

serverholic 6y ago

Having a consistent version number gives you some reassurance that your components are compatible with each other.