search

nuxt / rfcs

RFCs for changes to Nuxt.js
96 stars 2 forks source link

Release Plan #9

Closed pi0 closed 5 years ago

pi0 commented 5 years ago

Update

We have decided on a release plan which will take effect with v2.4. We try to abide to the plan as good as possible but it is thought as a rough schedule overview. There won't be an exact release date for most of the future versions.

Initial content

Current release lines:

Concerns:

manniL commented 5 years ago

I'd suggest the following:

LTS and release schedule

Having an LTS and a release schedule would help in several ways:

Releases

LTS

I'd declare every 2nd major version (2.x, 4.x, ...) as LTS with an overlapping period of 2 months (2 months after 4.x has been released, make it LTS)

Docs

We have to keep docs for each major version (every minor would be ideal but is impractical IMO).

Branches

Branches should be split by major version number (1.x, 2.x, ...). We can mark the LTS branch by adding LTS in the title somewhere.

The main branch should be the latest major version imo. (2.x at the moment)

pi0 commented 5 years ago

@manniL Some points:

manniL commented 5 years ago

@pi0

pi0 commented 5 years ago

You are right. Maybe half year majors are more than enough :D

I like these spec. But if making 2.x default branch for PRs, how often we should merge it into dev? I think dev should remain the default for non-breaking change PRs and next for breaking-changes and merge dev into 2.x for each release

manniL commented 5 years ago

You are right. Keeping dev as default would make much more sense 👍🏼

manniL commented 5 years ago

Also next is a nice idea 🙊

Atinux commented 5 years ago

I like all of these ideas, here's what I suggest based on your feedback:

LTS and release schedule

Only even number will have an LTS (2.x, 4.x, ...) like Node.js. About the overlapping or LTS period, I am up for suggestions, but I think the last even release should become LTS right after the new one, and for a period of time of 6 months.

Major releases

Every 6 months (or so) and I would like to announce it on a conference (like a Keynote).

Minor releases

Every month (3 weeks coding / merging + 1 week improving tests + coverage from the whole team, this is really important).

Patch releases

Every day if we need to, no special date, this what makes Nuxt great so people can have fixes quickly and not wait <3

Branches

Docs

We will have 1.x, 2.x, [...] edge and next.

Everytime we push to dev, we need and update to the edge docs (that will be displayed to the website with the version where it will be implemented) so then we only have to merge when releasing.

Everytime we push to next, we update the documentation too.

WE WRITE DOCS EVERYTIME WE PUSH SOMETHING, the documentation is what makes Nuxt sucessfull and we should not under-considerate it :)

pi0 commented 5 years ago

@Atinux Using nuxt@edge is dangerous because:

manniL commented 5 years ago

@Atinux Mostly agree with that. Some small considerations

Grace period between LTS versions

Having a major release roughly every 6 months and an LTS version every year is fine. However, forcing people to switch to the next LTS "instantly" could be a problem (eg. bugs or security issues in the first week of the new release worst case). I'd at least suggest a grace period of 4 weeks.

Feature freezes

We must declare feature freezes for upcoming minor releases. So we can fully focus on testing, fixing bugs and improving upcoming features.

Docs

I'd suggest that PRs in the core repo (that needs a doc change) will only be merged after a successful doc PR to make sure we have great docs :relaxed:

clarkdo commented 5 years ago

Some points I want to make them clear and discuss:

Major releases and LTS

  1. For now, major release and LTS may also relate to Vue, Webpack and some other critical dependencies's release and LTS.
  2. The LTS may also include compatibility and release version of Nuxt Community Modules(axios, auth...).
  3. If we published 3.x and 2.x is LTS, how to fix bugs for 2.x ? If works on 2.x branch, it breaks the rule that develops on dev. If works on dev branch, it's impossible to cherry-pick if in current strategy

Minor releases

  1. Is the release tag based on 2.x or dev ?
  2. Before publishing minor, are we going to merge dev or cherry-pick all commits except fix ? If merge dev, 2.x will contain duplicate fix commits, otherwise dev will never have a same commit tree as 2.x
  3. How to generate the change log minor release since it will include all feat and fix which has already covered in patch release.

Patch releases

  1. CI for patch branch(every push).
  2. Conditions of pr can be merged into 2.x,3.x branches.
  3. If a cherry-picked fix commit is changing same file line after a feat commit, how to handle it?
  4. Does patch release include dependencies patch version upgradation?
  5. Does patch release include non-feature refactoring?

Other Suggestion:

  1. Merging of PR requires at least 2 approved review.
manniL commented 5 years ago

@clarkdo Very good points!

For now, major release and LTS may also relate to Vue, Webpack and some other critical dependencies' release and LTS.

That's true! Vue, Webpack, Babel, Node.js, PostCSS are all dependencies our LTS has to carry with it. One more reason to keep LTS time not too long.

The LTS may also include compatibility and release version of Nuxt Community Modules(axios, auth...).

Could potentially be a problem (eg. new major auth-module version is not necessarily bound to work with LTS)

If we published 3.x and 2.x is LTS, how to fix bugs for 2.x ? If works on 2.x branch, it breaks the rule that develops on dev. If works on dev branch, it's impossible to cherry-pick if in current strategy

I'd suggest to create a PR (target: 2.x) and work there to backport that specific fix.

galvez commented 5 years ago

+1 on merging-after-docs as a written rule.

We've kind followed this already to some extent, but enforcing it is a good idea.

I have no major considerations after what @Atinux's comments.

I think we just need a proper yearly schedule (there are probably apps or templates for that) so everyone can track it.

manniL commented 5 years ago

The release plan will be published with v2.4

manniL commented 5 years ago

Final PR in https://github.com/nuxt/nuxt.js/pull/4853