From 73cea4b9db7272f2dfd017e49519cdf0bb730e7e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Szymon=20Mas=C5=82owski?= Date: Wed, 20 Apr 2022 13:45:11 +0200 Subject: [PATCH 1/2] Document new release flow --- README.md | 372 +++++++++++++++++++++++++----------------------------- 1 file changed, 171 insertions(+), 201 deletions(-) diff --git a/README.md b/README.md index e932ae48..16357add 100644 --- a/README.md +++ b/README.md @@ -6,10 +6,10 @@ your [webpack](http://webpack.github.io/) workflow, although you can use any oth ## Why? -* Existing React UI frameworks are too hard to customize. -* Overriding css styles is not enough for complex components. -* You need multiple variations of a component with shared logic. -* You need multiple, completely unique themes for your components. +- Existing React UI frameworks are too hard to customize. +- Overriding css styles is not enough for complex components. +- You need multiple variations of a component with shared logic. +- You need multiple, completely unique themes for your components. ## How: @@ -50,10 +50,10 @@ module: { Now you can import and use components like this in your app: ```js -import React from "react"; -import { Input } from "react-polymorph/lib/components"; -import { InputSkin } from "react-polymorph/lib/skins/simple/InputSkin"; -import { InputTheme } from "react-polymorph/lib/themes/simple/InputTheme"; +import React from 'react'; +import { Input } from 'react-polymorph/lib/components'; +import { InputSkin } from 'react-polymorph/lib/skins/simple/InputSkin'; +import { InputTheme } from 'react-polymorph/lib/themes/simple/InputTheme'; const MyInput = () => ( ( @@ -96,25 +96,39 @@ const SimpleFormApp = () => ( ## Release Managament - Starting with `1.0.0` all future releases will follow semver semantics: + - `patch` (eg: 1.0.x) for **API compatible bug fixes** - `minor` (eg.: 1.x.0) for **API compatible new features** - `major` (eg: 2.0.0) for **API breaking changes** - + - For early integration of upcoming release changes we use the following conventions: - - - `[current version]-next.x` to tag changes for upcoming releases (as we cannot know the necessary - semver for the final release including all the changes). `x` in this case is simply a number that + + - `[current version]-next.x` to tag changes for upcoming releases (as we cannot know the necessary + semver for the final release including all the changes). `x` in this case is simply a number that is increased and can be thought of like "slots" for temporary releases - - - All temporary releases should be published with the `next` npm dist tag via: `npm publish --tag next` + + - All temporary releases should be published with the `next` npm dist tag via: `npm publish --tag next` so that they are not automatically tagged with the default `latest` npm tag. - -- The `master` branch only includes commits of final releases - -- `release/x.x.x` branches are created as soon as we cut a release and know the correct semver - they - are always targeting the `master` branch + should be well documented. They can include many release - candidates which should be tagged like `[next releaes]-rc.X` where you increment X per release candidate - until we are confident that the release is ready to be published under its normal version. + +### The complete development flow considering the Daedalus + +1. You develop a feature on your branch without bumping the version +2. Once your code is ready to be tested in Daedalus, you [publish a temporary release](#how-to-publish-a-temporary-release): + +- checkout to your branch: +- change the version in package json to `[current version]-next.x` (only add the -next.X suffix keeping the current version) +- publish the version under the next tag +- **don't push the version change to upstream** + +3. When you receive a green light for merging from QAs and other devs on your PR in Daeadalus: + +- checkout to your branch +- bump the version in the package.json to the target one according to rules of semantic versioning +- add the changelog entry with your new version +- merge the PR do develop +- locally checkout to develop +- release the new version to npm +- use new version in your PR in the Daedalus ### How to publish a temporary release @@ -130,17 +144,15 @@ releases that might confuse others and are not following semver. ### How to publish a stable release -Stable releases are the next public version change of react-polymorph combining all previous temporary -releases into a semver based release: +Stable releases are the next public version change of react-polymorph within a semver based release: -1. Create a new `release/x.x.x` branch based on `develop` (following semver based on changelog) +1. Checkout to your branch 2. Update the version in `package.json` to the planned release version (do not tag it) 3. Update the `CHANGELOG.md` to assign the new release version to the last changes and upcoming changes -3. Setup a PR targetting `master` for the relase branch on Github and document the changes since last release -4. Publish a release candidate to npm (e.g: `1.0.1-rc.1`) -5. Integrate and test the release candidate -6. Iterate on the release via release candidates until its ready to be merged -7. Merge the release PR into `master` on Github and then `master` back into `develop` +4. Push changes +5. (person responsible for merging) Merge the PR into develop +6. Checkout locally to develop and pull changess +7. Publish the new stable version to npm ## Components and Skins @@ -161,19 +173,15 @@ Represents a single-line input field. ##### Example Usage: ```js -import React from "react"; -import { Input } from "react-polymorph/lib/components"; +import React from 'react'; +import { Input } from 'react-polymorph/lib/components'; // Standard input component: const MyStandardInput = () => ( - + ); ``` - ##### Input Props: ```js @@ -195,7 +203,7 @@ type InputProps = { skin?: ComponentType, theme: ?Object, themeOverrides: Object, - value: string + value: string, }; ``` @@ -210,9 +218,9 @@ Component specialized in guiding the user to enter correct floating point number ##### Example Usage: ```js -import React from "react"; -import { NumericInput } from "react-polymorph/lib/components"; -import { InputSkin } from "react-polymorph/lib/skins/simple"; +import React from 'react'; +import { NumericInput } from 'react-polymorph/lib/components'; +import { InputSkin } from 'react-polymorph/lib/skins/simple'; const MyNumericInput = () => ( ( ##### Expected Behavior: Since there is no web standard on how to build numeric input components, here is the specification we -came up with that serves our purposes in the best way: +came up with that serves our purposes in the best way: - Only numeric digits `[0-9]` and decimal separators (configurable via `bigNumberFormat` prop) can be entered. - When invalid characters are pasted as input, nothing happens @@ -292,15 +300,15 @@ You can configure the rounding mode by passing in any valid [bignumber.js ROUNDI #### Textarea -Simple component that represents an input which can receive multiple lines of text. +Simple component that represents an input which can receive multiple lines of text. ![Standard Input](./docs/images/react-polymorph-textarea-example.png) ##### Example Usage: ```js -import React from "react"; -import { TextArea } from "react-polymorph/lib/components"; +import React from 'react'; +import { TextArea } from 'react-polymorph/lib/components'; const MyTextArea = () => (