versioning

[tj]

as discussed in #components we'll soon have to implement the semver portion and adding warning for incompatibilities. There are a few ways we could approach this, the most correct way being addition requests to fetch the tags per component, which adds some annoying overhead that we may end up having to cache to keep component-install(1) nice and speedy. Alternatively we optimistically fetch all the versions as demanded, then apply semver checks and ensure everything is within range.

If there's a conflict we could either warn, or actually include the duplicates though this would complicate the builder and many other aspects of the system. My opinion is that a major version change is an API failure, they will happen, however with components being small we should have relatively few of these cases, so going with no duplicates should be reasonable

[andrewrk]

I would encourage sticking to npm's philosophy of duplicating dependencies if the versions don't match. I would argue that correctness is more valuable than smallness.

We don't have to give up smallness, however. We could try to use the same versions when the version locking allows and output warnings when duplicates must be used.

[tj]

yeah I think there will be a surprisingly small number that conflict at the minor level. supporting both wouldn't be a huge stretch, we'd just have to change module.register() calls to include the major number and alias accordingly

[matthewp]

As an alternative to semver it would be nice to include a specific commit hash in your dependencies. This should work right now (haven't actually tried it), but I'd like to see it be officially supported.

"dependencies": {
  "component/emitter": "3d5b12b113ca67a8c23d94aca74d18e9b70a72b7"
}

[anthonyshort]

Surprised more people haven't been pushing for this. We're currently running ~50 components across multiple corporate sites and semver resolution would lower the amount of manual work we have to do with versions. I even tried to use bower for dependencies and component to build 😢

Is there anything I can do to help get this started? I'm happy to start working on some code for this if you've got an idea of how you'd like it to work.

[tj]

I'm somewhat meh when it comes to semver, often in patch-level bugs change the behaviour of your application because you code around them, but I would like to at least support the 1.x sort of syntax, the rest is pretty useless. It should be pretty easy to implement though we just have to start storing the component dirs as <user>-<repo>-<version> and query the repo's tags.

[smagch]

Really? Only 1.x syntax? No >, >=, <, <=, ~ syntax? How can I specify a version when I want a module greater than 1.3 and less than 2.0? Requiring 1.3.x will be likely to produce duplication because other module would require 1.2.x at the same time. Optimistic dependencies declaration is what semantic versioning is good at.

[tj]

most of the options are silly IMO, a little duplication until resolved is better than a lot of broken apps. It's extremely tempting to disallow even 1.x and similar, it's easy for your application to break even with a patch-level change, it may regress, or you may have coded around the bug previously in which case your app may regress. If anything I think x and ~ would be all I really want to support but it'll likely use node-semver anyway we'll see, it does get annoying to maintain explicit versions

[smagch]

a little duplication until resolved is better than a lot of broken apps

Fair enough. I haven't had a serious issue that minor/patch upgrade of modules break my app. When I first used npm and saw semantic versioning spec, I though it's really cool. I though it's cool to use the latest source without being afraid of breaking an app.

As long as I use only public API method of a module, it won't break my app with minor/patch upgrade theoretically unless the module author break semantic versioning convention. I know it isn't actually; I'm always locking uglifyjs's version in order to make sure minification succeed.

Anyway, I'm glad to hear that ~ syntax is to be supported.

[timoxley]

I though it's cool to use the latest source without being afraid of breaking an app.

Good in theory but doesn't work so well in practice. According to http://semver.org/:

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

Notice most (almost all?) components are in 0.y.x state, therefore semver is of little value for consumers of these apis.

[tj]

no matter how much you try and follow semver there's always things you'll get wrong, regressions happen, even if your release promises a bugfix it may introduce other bugs :D

[wyuenho]

no matter how much you try and follow semver there's always things you'll get wrong, regressions happen, even if your release promises a bugfix it may introduce other bugs :D

That pretty much sums up supporting semver probably should be done anyway. You can't prevent other people from breaking things and not supporting it just confuses people because that breaks the convention. It took me a while to figure this out as it is not mentioned in the docs.

[tj]

yeah we'll have to add it at some point

[tj]

it would be easier to implement after the registry migration though

[Swatinem]

👍 for ~ x.y.z versioning

[jasonkuhrt]

Based on my limited experience the use-cases I've hit the most are:

• Using semvar to spec an exact version 1.2.3
• Using semvar to bind on the latest patch 1.2.x (despite caveats noted in this thread)
• Using a git tag (if people are semvar tagging then it ends up being equatable to using semvar, just less direct)
• Using a git commit id
• Using a git branch name (implicitly meaning the HEAD of that branch)
• Using '*' to imply a git master branch HEAD seems fair

npm offers a boat-load of options I've never memorized or used.

[jonathanong]

moving convo to: componentjs/spec#1

[yields]

i think this should be opened ? it's not implemented

//cc @jonathanong

[jonathanong]

sure.

[wyuenho]

Any progress on this front BTW?

[jonathanong]

Yeah I'm going to try to do this tonight. It's been distracting me from other stuff so I kind of have to :/

[jonathanong]

and it would be basically a full rewrite, so it won't be pushed until a lot of tests go in

[wyuenho]

If you could break this out into a list of smaller tasks then new people will probably have an easier time to help out if they want to. This issue is pretty critical I think.

[ianstormtaylor]

@anthonyshort has been doing something?

[anthonyshort]

I have a fork that installs and builds with multiple versions, but it doesn't use semver yet, so every version is added to the build. This means there are never any conflicts with the versions, but it could theoretically get quite large.

Personally, I don't really care that every version is added to the build if it means component stays simple. A few extra KB to keep life simple with plain versioning.

Most people won't like this though. But it won't really work until we get semver which we can't get until we have a registry (mostly).

[jonathanong]

yeah that's why i wanted to wait for the registry. but we should support github, bitbucket, etc. anyways in case the registry fails or something.

[wyuenho]

What is this registry you speak of and why do you need one?

[kenany]

@wyuenho #429

[wyuenho]

Doesn't say why tho. I don't see a functional dependency between a registry and semver support.

[jonathanong]

it would just make things easier as the registry can handle the semver logic. not a big deal though

[wyuenho]

Why would you move this computation to the server? Traversing a dep graph is potentially expensive, and also for redundancy's sake, in case the registry goes down, you'll still need to be able to fetch from github/bitbucket etc, like how component already does anyway. A registry is good for searching but that's pretty much it.

[jonathanong]

yeah i have it generally working for github now. working on the builder now

[wyuenho]

👍

[tj]

semver resolution being on the server would simplify things quite a bit, otherwise we'll have to make a lot of api calls to github to fetch the versions etc. I contacted Github to see how they felt about projects using them as a registry and they're not too fond of it, but they didn't mention any explicit restrictions

[wyuenho]

semver resolution on the server would make writing clients easy, but that shouldn't be the first thing to worry about unless the registry and related work can be done quickly?

[wyuenho]

My point is, for robustness, semver resolution will have to be done on both sides anyway...

[marcelklehr]

Isaacs has published a nice package for dealing with semver madness: https://npmjs.org/package/semver

[jonathanong]

semver is more complicated than just using the package. i have semver going in https://github.com/component/resolver.js. you can try it with https://github.com/component/watcher.js but it's a little hacky right now

[jonathanong]

master w00t w00t