From 53141cc65816cc88174cf4436fb322d4c6b21bc5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Harry=20Tr=E1=BA=A7n?= Date: Wed, 4 Dec 2019 22:29:53 +0700 Subject: [PATCH] chore(docs): update code-of-conduct (#6719) --- CODE_OF_CONDUCT.md | 24 ++++++++++++------------ RELEASE_PLAN.md | 28 ++++++++++++++-------------- 2 files changed, 26 insertions(+), 26 deletions(-) diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index a91492b217..2c952b6697 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -8,19 +8,19 @@ In the interest of fostering an open and welcoming environment, we as contributo Examples of behavior that contributes to creating a positive environment include: -* Using welcoming and inclusive language -* Being respectful of differing viewpoints and experiences -* Gracefully accepting constructive criticism -* Focusing on what is best for the community -* Showing empathy towards other community members +- Using welcoming and inclusive language +- Being respectful of differing viewpoints and experiences +- Gracefully accepting constructive criticism +- Focusing on what is best for the community +- Showing empathy towards other community members Examples of unacceptable behavior by participants include: -* The use of sexualized language or imagery and unwelcome sexual attention or advances -* Trolling, insulting/derogatory comments, and personal or political attacks -* Public or private harassment -* Publishing others' private information, such as a physical or electronic address, without explicit permission -* Other conduct which could reasonably be considered inappropriate in a professional setting +- The use of sexualized language or imagery and unwelcome sexual attention or advances +- Trolling, insulting/derogatory comments, and personal or political attacks +- Public or private harassment +- Publishing others' private information, such as a physical or electronic address, without explicit permission +- Other conduct which could reasonably be considered inappropriate in a professional setting ## Our Responsibilities @@ -40,7 +40,7 @@ Project maintainers who do not follow or enforce the Code of Conduct in good fai ## Attribution -This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version] +This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]. [homepage]: http://contributor-covenant.org -[version]: http://contributor-covenant.org/version/1/4/ +[version]: http://contributor-covenant.org/version/1/4 diff --git a/RELEASE_PLAN.md b/RELEASE_PLAN.md index 843f05f733..89dcfd2ea1 100644 --- a/RELEASE_PLAN.md +++ b/RELEASE_PLAN.md @@ -1,49 +1,49 @@ ## Release Plan Starting with version `v2.4`, Nuxt will adhere to a formalized release plan (as good as possible). -Also, an end of life for older major versions is defined with this document +Also, an end of life for older major versions is defined with this document. ### Major versions (3.x -> 4.0) Nuxt major releases are planned every **6 months**. This depends on a few factors though: -* If there are no breaking changes waiting for a release, no new major version will be published. Instead, another minor one will be released. -* In case of unexpected major updates of important dependencies like Vue, Webpack, and so on, major versions might be released *earlier* than planned. +- If there are no breaking changes waiting for a release, no new major version will be published. Instead, another minor one will be released +- In case of unexpected major updates of important dependencies like Vue, Webpack, and so on, major versions might be released _earlier_ than planned The goal is to provide a **migration guide** for each major version as well, as escape hatches, so existing code won't "just break". ### Minor versions (2.1 -> 2.2) -The release cycle for Nuxt.js minor versions is roughly **4 weeks**. +The release cycle for Nuxt.js minor versions is roughly **4 weeks**. -Three of the four weeks will be used for actual **feature implementations** while the last week will be used for +Three of the four weeks will be used for actual **feature implementations** while the last week will be used for **testing, fixing bugs and thorough audits**. -That also means a *feature freeze* for the next minor version after these three weeks. -Features that aren't ready will be moved to the next cycle. "Waiting" for features +That also means a _feature freeze_ for the next minor version after these three weeks. +Features that aren't ready will be moved to the next cycle. "Waiting" for features (for a longer time) will be avoided as good as possible to keep releases lean, concise, predictable and digestible. ### Patch releases (2.2.3 -> 2.2.4) -The last patch releases were mostly *bundled* fixes or single *hotfixes*. -In the future, fixes will be released **as soon as possible** after the actual PR/commit so people won't have to switch to `nuxt-edge` for bugfixes. This should improve the stability of Nuxt +The last patch releases were mostly _bundled_ fixes or single _hotfixes_. +In the future, fixes will be released **as soon as possible** after the actual PR/commit so people won't have to switch to `nuxt-edge` for bugfixes. This should improve the stability of Nuxt. Fixes can or will include: -* Updates of dependencies (for various reasons, like a "faulty/buggy" dependency or an newer versions that works better with the Nuxt.js code) -* Fixes for our code +- Updates of dependencies (for various reasons, like a "faulty/buggy" dependency or an newer versions that works better with the Nuxt.js code) +- Fixes for our code Bugfixes for upcoming features won't be ported of course. ### Edge Release Channel -After experimenting with `nuxt-edge` releases in the last time, the decisiion to do **nightly releases** for now instead of -releasing a version after *each commit* was made. +After experimenting with `nuxt-edge` releases in the last time, the decisiion to do **nightly releases** for now instead of +releasing a version after _each commit_ was made. ## End of Life Starting with `v2.4`, every major Nuxt.js version will have an **End of Life**. -Previous releases will receive security updates and bugfixes **for one year and two weeks**, counted from the first release on. +Previous releases will receive security updates and bugfixes **for one year and two weeks**, counted from the first release on. As Nuxt majors are approximately released once every 6 months, this will allow developers to "skip one major version" without being stuck with a broken or unsecure Nuxt.js dependency. The EOL also applies to the documentation.