diff --git a/README.md b/README.md
index e932ae48..2bbca2c5 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` (just add the -next.X suffix keeping the current version)
+- publish the version under the next tag
+- you don't need to push the version change to upstream as you will be changing it again shortly.
+
+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.

##### 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 = () => (