Rethink about versioning

pi0 commented 5 years ago

Concerns are:

1- Dependent or Independent

While we've chosen independent versioning for Lerna, the way of our release/announcements, linking dependencies, docs and even planning is dependent! (2.3,2.3.1,2.4,3,...)

2- What should be exactly considered a fix/feat and breaking change?

Myself am always a fan of adding features as fixes :D But the term fix should have a clean scope, boundaries, and definition to always stick with it. Bumping semver/minor is always free! But risks to stressful releases and unwanted regressions is not.

3- Stable Release

This concern is big enough to be splitted into sub-issues and is dependent on our marketing strategy, release plans, and branch handling. Just added to the list!

4- Ensuring Lerna changelogs are valid and unified

pi0 commented 5 years ago

My thoughts regarding (1): We have choices:

[dependent] (Current!) bump distribution versions according to their listed deps. This means if we add a fix to @nuxt/cli, nuxt/nuxt-start/nuxt-edge version will be bumped by 1 patch.
[independent] (The ESLint way!) All dependencies (@nuxt/core/@nuxt/builder/etc) should be explicitly listed in project main package.json. Not an elegant way and also breaking change. But gives more control and remove the need of bumping distro versions.

While we can't mix up 1 and 2 and if we decide to stay with 1, versioning should be dependent we can do some improvements for it but still, distributions should be released after patch to any dependency

Relaxing deps at patch level: This way nuxt depends on @nuxt/cli:~2.3.x. This means no more features but always latest fixes.
Picking up manual added deps: If user adds an specified version of @nuxt/ui in his project we pick up that. CLI improvement for this enhancement is already done.
[You Say]

aldarund commented 5 years ago

i think for 2.x we should stick with #1 + improvements mentioned. For 3.x we can consider #2 , although maybe provide some command to manage it like nuxt upgrade, nuxt verify

manniL commented 5 years ago

dependent won on a Discord vote :relaxed:

Atinux commented 5 years ago

Honestly, for core package, we can stay with dependent versionning for 2.x and see how it goes. I guess when doing a release of nuxt, we will explain the changes that affect all users.

People don't really need to understand our internal package refactoring.

nuxt / rfcs

Rethink about versioning #8