Severe semver issues!

[jods4]

There is a severe issue with the versioning scheme.

Apparently bower considers 1.0.0 a patch upgrade of ~1.0.0-rc.1.0.1.

Result: we got the upgrade unwillingly and it contained a regression for us (specifically my comment in aurelia/router#366).

But it gets much worse!
We tried to fix it by requesting the specific version "aurelia-bootstrapper": "1.0.0-rc.1.0.1" but it won't work either!
Bootstrapper requests its dependencies with "aurelia-***": "^1.0.0-rc.1.0.1", which means that although we get the RC version of bootstrapper, we still get the 1.0 release of aurelia-router.
So short of specifying all packages resolutions ourselves in bower.json, we're stuck in a situation where we cannot get a working release.

I believe the proper fix is that internal Aurelia packages should depend on specific versions, no ^ or ~. And when a package is patched, you should publish new releases all along the dependency chain up to the top aurelia-bootstrapper package.

Aside: this might be an example where using the bundled Aurelia core is not only simpler, but less fragile. Do you think you should publish the bundled package on Bower & co in addition to CDNs?

[EisenbergEffect]

We're not going to do that. Sorry.
I would recommend you file a bug with the bower team.

[jods4]

Just sayin: the fact is that this morning our application was broken and there was almost nothing we could do to get a working aurelia library. This may happen again in the future every time you introduce a bug in a PATCH (in the sense: MAJOR.MINOR.PATCH).

I don't see what I could say to the bower team. They follow semver + node ranges, as described here:
https://github.com/npm/node-semver#tilde-ranges-123-12-1

Specifically, when you use ~1.0.0-rc.1 it turns to >=1.0.0-rc.1 <1.1.0. So it is totally correct to update to 1.0.0 (which is according to semver bigger than pre-release tags).
So bower is totally correct in its fetching of packages.

This means that the way you distribute Aurelia, when we import aurelia-bootstrapper: '1.0.0-rc.1' we will always get the latest PATCH of other aurelia packages, even if they are buggy.

It seems pretty bad to me.

[doktordirk]

just update all to release version and the problem us solved

[jods4]

@doktordirk I think you miss the point.
This issue is about what happens when the "update all to release version" is broken.

As a specific example, it's what happened with 1.0.0, which contained a regression preventing our app from even starting (now fixed in 1.0.2).

I think that for various reasons, especially bugs, people may want to stay on a previous version. This is currently hard to do.

[doktordirk]

i agree, it is and it was imho a mistake not to stick to npms version of semver. i just wanted to point out, that is was a one time thing, and from now on for users who updated to release they won't have that problem. it's not an issue which will haunt us much longer. particularly since the last rc is the same anyways - other than the router which is also fixed now .

[jods4]

Not sure I follow how this is not an issue anymore and won't happen again.

Imagine tomorrow Aurelia publishes a broken aurelia-templating version 1.0.3. Guess what? You will get it and will have a hard time going back.

I think that for most libraries, the ability to request a specific version and get it is generally assumed. Many teams want to control their upgrade process, even for patches releases. This is risk management.

What breaks the "I want a specific version" thing is that Aurelia is distributed in fragmented packages (with aurelia-bootstrapper as an umbrella for the core) and they don't evolve in locked steps. Requesting a specific version does not guarantee that you'll get specific versions of its dependencies.

[doktordirk]

hmm, i see what you mean. with jspm though it's easy enough to fix the dependencies' version. dunno about bower. but if it's not possible there and it can't be fixed on bowser's side, than i think, asking Rob to only fix the dependencies in the bower.json's but keeping the caret elsewhere, might have chances

[EisenbergEffect]

Generally, I think this is up to the end user. If you want, you can lock your versions. We aren't planning to update any dependency versions in our packages unless there's a true dependency need from here on out. You can control what you want on your end.

[jods4]

@EisenbergEffect This isn't as "nice" as it might be with JSPM. There is no lock file automatically generated and maintained for you in Bower...

I say "hard" but not "impossible" because I think you can work around this using resolutions inside bower.json.
First drawback is that many people are totally unaware of this property.
Then, if you don't want to mix-and-match releases (which I would think a bad practice), you would need to discover and fill in all your dependency tree manually. And keep this updated manually.

Is there another way that I'm unaware of?

[EisenbergEffect]

Is there some reason you are using bower instead of npm? Bower has a lot of issues and they haven't been addressed even over a very long time. I would recommend thinking of using a more robust package manager solution.

[jods4]

@EisenbergEffect Kinda, yes.

At work we need to be efficient so we like things that are here to stay, have a widespread usage and some proved stability/robustness.

It seems to me that Bower is still the most well established front-end package manager.
That's the same reason we run requireJS / AMD. And it worked awesome for our first project while I watched the struggles with SystemJS (which starts to seem attractive, maybe for future projects).

JSPM is interesting but too new and has encountered many problems/changes so far. We are watching if it's going to get a wide adoption, but for now it seems too early.

NPM we use as well, for our build tools. I see some movement towards NPM for front-end, especially after the 3.0 release and the flat folder structure, but we want to watch if this will catch up or not first -- it's too new for now. Also, having Bower separated from NPM means that our build can just automatically assemble everything inside bower_components, that's very nice. We could work out something with NPM (devDependencies vs dependencies) but we haven't yet.

We are always open, but we need to be pragmatic at work. We have used Bower a lot, we know it well and it works for us.