Is Yarn 2 in maintenance before Yarn 3 is released?

[bryanvaz]

Quick question: What is the bug fix policy around Yarn 2 before Yarn 3 is formally released? (assuming that the RELEASE CANDIDATE moniker is because Yarn 3 is not considered production stable yet)

Bug #2232 is a critical bug that prevents Vue developers from moving from Yarn 1 to Yarn 2. However, even though the bug was patched and merged, it was only merged into the Yarn 3 branch and it was actively decided not to be applied to Yarn 2.

In this situation what are Vue developers supposed to do in a production environment?
The feedback on the issue was to either just suck it up and use Yarn 3 RC, or just continue using Yarn 1 and stop complaining. Hence the confusion about the Yarn 2 bugfix & maintenance policy; this seems the perfect example of bug that should be applied to Yarn 2 since it was caused by an incorrect implementation of the fake fs module.

For background, vue-jest which is required by Vue devs to unit test VueJS apps uses deasync in its dependency tree, and deasync uses BigInt during the postinstall step which causes the issue.

Cheers,
Bryan

[arcanis]

Simply put, we don't have a formal LTS system. Features and bugfixes are developed on top of master, and published with the next release. We don't usually backport those fixes, because we are a small team and have to prioritize our work (as a data point, Vue's annual budget is $105,000, Yarn's $746).

Note is that master is usually very stable - Yarn itself runs on the master sources themselves, and only things that pass our testsuites are merged, bar unforeseen issues. There's a reason why we provide a command to easily install a build straight from there.

[merceyz]

use Yarn 3 RC, or just continue using Yarn 1

You can use Yarn v2 with node_modules, the issue is only for PnP.

[bryanvaz]

Ohhhh ok. So what you're saying is that even though Yarn 2 is the "current release" and Yarn 3 is the unreleased, there is actually only one branch, master, which is the Yarn 3, and Yarn 2 is no longer maintained.

Also around the "small team" and limited budget, are you saying you're in the same situation openssl was facing in the months and years leading up to the heartbleed exploit? (namely an imbalance between userbase vs. supporting team size/budget?)

[arcanis]

and Yarn 2 is no longer maintained.

I kinda take issue with this wording - from my perspective Yarn 2 and 3 are the same thing, with 3 just having a little bit more potential breaking changes (not that much, if you check the changelog) than you'd find in a minor release. To say it's "not maintained" is imo confusing for readers, as I read it as implying bugs aren't worked on at all.

Also around the "small team" and limited budget, are you saying you're in the same situation openssl was facing in the months and years leading up to the heartbleed exploit? (namely an imbalance between userbase vs. supporting team size/budget?)

I'm not aware of the details of the OpenSSL project, but it's clear that there are things we can improve in terms of sustainability. Not that much efforts have been dedicated to this purpose yet (the OpenCollective itself is fairly new), but that's something we keep in mind.

As for Heartbleed itself (in case you're worried about the security aspect in particular), I believe the situation was fairly different. I distinctly remember that a common topic at the time was that OpenSSL was known to have a very complex architecture prone to this class of bugs (which prompted the LibreSSL effort). By contrast, Yarn has a more controlled & very modern interface (after all we redesigned it about two years ago to leverage what we have learned in the past years), and we feel fairly confident in what we have today.

Finally, we're also reasonable developers. If there's a critical reason to backport a fix (for example a security issue), then we'll consider it. It just incurs extra work, and thus isn't the default.

[lewiji]

I kinda take issue with this wording - from my perspective Yarn 2 and 3 are the same thing, with 3 just having a little bit more potential breaking changes (not that much, if you check the changelog) than you'd find in a minor release. To say it's "not maintained" is imo confusing for readers, as I read it as implying bugs aren't worked on at all.

I have just come here after some confusion experiencing #2074 on node 15, using version berry, and also when using yarn set version latest (at the time of writing, 2.4.1, the same as berry). I also found similar, more recent #2486. In both cases the suggested path to bring in the fixes was yarn set version from sources - firstly it surprised me that fixes from February weren't available in the berry release line, but being able to easily upgrade yarn version from CLI, that was fine. Upon running it I saw that it upgraded from 2.x to 3.x, and I had to remove and reimport some config (eg the plugin for workspaces imported from sources) to be able to run any yarn commands at all.

I understand your explanations above and appreciate that you guys are working hard on delivering the best version of yarn, but for me, the confusion (as a reader) wasn't in the statement:

Yarn 2 is the "current release" and Yarn 3 is the unreleased, there is actually only one branch, master, which is the Yarn 3, and Yarn 2 is no longer maintained.

Which seemed accurate from my experience, given that the conditions for the bug were running yarn 2.x release or latest branch on node 15 with workspaces, fixes for which were merged into master in February, and the suggested way to bring the fixes in were get the master branch version which brings in 3.x.

So my confusion lies in what the major versioning in yarn actually implicates, since the upgrade from v1 to v2 was quite a marked difference in configuration and usage, the fixes I would have expected in yarn set version latest didn't seem to be present (unless it's a regression?), and the issues were considered fixed as long as it worked in 3.x - which, by the way, does now work with my use case, but I'm uncertain what else I'm bringing in or what to expected from using 3.x over 2.x. Am I on "yarn v3" now?

From the maintainer's/contributor's point of view this is obviously the most efficient way to keep on top of things, but from the developer's point of view it's confusing and it does indeed seem a bit like "v2" is abandoned if they run across issues that can only be solved by upgrading to master.

[arcanis]

So my confusion lies in what the major versioning in yarn actually implicate

Simply that the particular transition from 2.x to 3.x may include breaking changes, and that you should take a look at the changelog a bit more than usual. From 1.x to 2.x it was a huge leap because we had/aimed to rework the whole architecture, but from now on major upgrades are expected to have far less disruptive scopes.

In fact, I toyed at some point with the idea of distributing the CLI using CalVer rather than SemVer... perhaps someday. This thread certainly shows that it would remove some confusion 🙂