Consider revisiting yarn update policy

[Hypnosphi]

Sometimes patch updates contain some critical bugfixes. This is the case for yarn 1.2.1 (1.2.0 installs wrong dependencies sometimes).

I understand the reasons behind current update policy, but it leaves the latest image in kinda broken state until new node version is released. So maybe you should consider syncing only minor version with the one of node, so that it’s possible that 8.7.1 actually installs node v8.7.0 (and has a patch update for yarn)

[pesho]

This might be worth considering now. The current policy was adopted when Yarn was still at the 0.x stage and every update carried a risk of introducing new bugs. Now that it has reached 1.x, SemVer PATCH updates should be much more likely to fix existing bugs, rather than introduce new ones (cc @Daniel15 @bestander for their opinion).

@Hypnosphi care to propose a PR updating the policy (in CONTRIBUTING.md)?

[SimenB]

I disagree. This should be the same as with npm - we don't update that even if it's buggy between releases either.

If a very critical bug is there, I'd rather have exceptions. Having yarn change from under my feet would be annoying (and the tag of the image should match the node version)

[Hypnosphi]

Is it possible to update latest, 8, and 8.7 images without updating 8.7.0?

I will make a PR as soon as there is some agreement about it

[Hypnosphi]

BTW, what to you do with version when the image code itself needs a bugfix?

[chorrell]

We should stick with the same approach as npm. I agree with @SimenB, I'd rather make exceptions for critical bug fixes.

[nschonni]

Maybe overly complicated, but what about adding a YARN_VERSION file to the version folders, and only invoke the update to the version number in

docker-node/update.sh

Line 20 in d3ca6d8

yarnVersion="$(curl -sSL --compressed https://yarnpkg.com/latest-version)"

if the PATCH version number is supplied/changed?
That would match what is in the CONTRIBUTING.md, and prevent accidental bumps when running update.sh with no version parameter

[carl-utter]

IMHO @nschonni is recommending the correct solution:

1. It allows the docker-node team to continue their preferred update/release paradigm (npm-ish)
2. It allows developers to use the node:8.7.x docker image with yarn "up-to-date"
3. It will prevent a bunch of user-modified node:8.7.x docker images from springing up all over the place (as if there isn't enough already).

NOTE: I'm about to create one myself because I have requirements and expectations to meet for my project and they include docker, [email protected], and [email protected].

[hersonls]

Here in my environment we had problems with the version Yarn 1.2.0 and subtree dependencies. The bugfix in the 1.2.1 solve the problem. We need some approach for this kind of release.

[SimenB]

I'd rather change how we install yarn in the first place to allow users to update it themselves without too much hassle

[chorrell]

I agree.

[Daniel15]

If you want to allow users to easily update Yarn, probably the best approach (at least for the Debian based images) is to switch to using the Debian package. I think there's already an issue for that. A user that wants to use a different version of Yarn could simply have their own layer on top of this image that installs a different version (eg. `apt-get install yarn=1.0.0-1`). Users can upgrade Yarn at the moment, but they need to know to manually extract the tarball into the correct directory. Sent from my phone.

…

On Oct 21, 2017 8:49 AM, "Christopher Horrell" ***@***.***> wrote: I agree. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#547 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFnHVXW4gSvxyqSSQ5Wucl2qDg1nCmLks5suhKYgaJpZM4P4gwA> .

[SimenB]

There's an issue for this, yes: #524

We should probably start by adding some docs on how to update yarn today, as #524 has some outstanding issues.

[bestander]

Yarn is here for the long term, it is driven by the people who use large and complex JS systems in production.
People tried waiting for the "mainstream" stack to address the issues but it was easier to start from scratch because early decisions of npm could be reconsidered.

[SimenB]

@rayfoss this issue isn't about whether yarn should be in the image at all. I'm not sure what downsides you think there are by having yarn included, but this issue is not the place to discuss it.

If you want to discuss it you should open up a separate issue, but I can say with some certainty that we won't be reversing this decision anytime soon, it has been by far our most requested change. See #243 for original request.

[davidkarlsen]

Any progress on this? I'd like to move to yarn 1.5.1

[chorrell]

yarn 1.5.1 will be in the v6.13.1 and v8.10.0 images

[davidkarlsen]

Why not 9.7.x too?

[davidkarlsen]

Ah - already in place - never mind me!

[chorrell]

Closing since we update to the latest yarn whenever we push out a new node.js version.