-
Notifications
You must be signed in to change notification settings - Fork 280
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #874 from liferay/feature/contributing
Fixes #873 - Adds Contributing Guidelines and Release process documentation
- Loading branch information
Showing
4 changed files
with
134 additions
and
2 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,126 @@ | ||
# Contributing Guidelines | ||
|
||
If you wish to contribute to AlloyEditor these guidelines will be important for | ||
you. They cover instructions for setup, information on how the repository is | ||
organized, as well as contribution requirements. | ||
|
||
## Setup | ||
|
||
TBD | ||
|
||
## Repo organization | ||
|
||
TBD | ||
|
||
## Pull requests & Github issues | ||
|
||
* All pull requests should be sent to the `develop` branch, as the `master` | ||
branch should always reflect the most recent release. | ||
* Any merged changes will remain in the `develop` branch until the next | ||
scheduled release. | ||
* The only exception to this rule is for emergency hot fixes, in which case the | ||
pull request can be sent to the `master` branch. | ||
* A Github issue should also be created for any bug fix or feature, this helps | ||
when generating the CHANGELOG.md file. | ||
* All commits in a given pull request should start with the `Fixes #xxx - ` | ||
message for traceability purposes. | ||
|
||
## Tests | ||
|
||
Any change (be it an improvement, a new feature or a bug fix) needs to include | ||
a test, and all tests from the repo need to be passing. To run the tests you | ||
can use our npm script: | ||
|
||
``` | ||
npm test | ||
``` | ||
|
||
This will run the complete test suite on Chrome. For a full test pass, you can | ||
add local browsers to the root `karma.js` file and re-run the command. | ||
|
||
Additionally, you can also run the test suite via Saucelabs with the following | ||
npm script: | ||
|
||
``` | ||
npm testSaucelabs | ||
``` | ||
|
||
This last command is the one used by our CI integration. | ||
|
||
## Formatting | ||
|
||
TBD | ||
|
||
## JS Docs | ||
|
||
All methods should be documented, following [google's format](https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler). | ||
|
||
# Releasing | ||
|
||
Collaborators with publish permissions should follow these steps. | ||
|
||
There are two different workflows for publishing this project, one for scheduled | ||
releases, and one for emergency hot fixes. | ||
|
||
## Scheduled release | ||
|
||
1. Create a release branch from the updated `develop` branch | ||
|
||
``` | ||
git checkout develop | ||
git pull upstream develop | ||
git checkout -b release/vX.X.X | ||
``` | ||
|
||
2. Send release PR to `master` | ||
|
||
3. Wait to see that all tests pass and then merge with merge commit | ||
|
||
4. Checkout and pull `master` locally | ||
|
||
``` | ||
git checkout master && git pull upstream master | ||
``` | ||
|
||
5. Publish npm modules and push release tags | ||
|
||
``` | ||
lerna publish (major/minor/patch accordingly) | ||
``` | ||
|
||
6. Generate changelog | ||
|
||
github_changelog_generator (https://github.com/skywinder/github-changelog-generator) | ||
|
||
7. Commit changelog and push to `master` | ||
|
||
``` | ||
git add CHANGELOG.md | ||
git commit -m "Updates CHANGELOG for vX.X.X" | ||
git push | ||
``` | ||
|
||
8. Sync `develop` with `master` | ||
|
||
``` | ||
git checkout develop | ||
git merge master | ||
``` | ||
|
||
9. Do GitHub release using the pushed vX.X.X tag and the appropriate portion of | ||
CHANGELOG.md | ||
|
||
## Hot fix | ||
|
||
1. Create a feature branch from `master` (assuming hot fix has already been | ||
merged) | ||
|
||
``` | ||
git checkout master | ||
git pull upstream master | ||
git checkout -b feature/fix_foo | ||
``` | ||
|
||
2. Send a fix PR to `master` | ||
|
||
3. Follow steps 3-9 of a scheduled release |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters