summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorFred Hebert <mononcqc@ferd.ca>2015-06-29 08:47:25 -0400
committerFred Hebert <mononcqc@ferd.ca>2015-06-29 08:47:25 -0400
commit4f981061f3ed3a89c2f1fad41601d8adaff9ecc5 (patch)
tree9f1be9f47d43a33469a32dbf744e110a1b836556
parent9803bb93fab58f3c7e4fe26af3294b15ed55cfca (diff)
parent4e410b6d6ec1a1c23edcaeee67192be982097cad (diff)
Merge pull request #558 from tsloughter/beta-1
update contributing, readme and app.src for beta-1
-rw-r--r--CONTRIBUTING.md67
-rw-r--r--README.md13
-rw-r--r--src/rebar.app.src2
3 files changed, 26 insertions, 56 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index e0de0eb..4643725 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,7 +1,7 @@
Contributing to rebar
---------------------
-Before implementing a new feature, please submit a ticket to discuss your plans.
+Before implementing a new feature, please submit a ticket to discuss your plans.
The feature might have been rejected already, or the implementation might already be decided.
See [Community and Resources](README.md#community-and-resources).
@@ -16,20 +16,20 @@ The following rules must be followed:
The following rules should be followed:
* Write small functions whenever possible
- * Avoid having too many clauses containing clauses containing clauses.
+ * Avoid having too many clauses containing clauses containing clauses.
Basically, avoid deeply nested functions.
[erlang-mode (emacs)](http://www.erlang.org/doc/man/erlang.el.html)
-indentation is preferred. This will keep the code base consistent.
+indentation is preferred. This will keep the code base consistent.
vi users are encouraged to give [Vim emulation](http://emacswiki.org/emacs/Evil) ([more
info](https://gitorious.org/evil/pages/Home)) a try.
Pull requests and branching
---------------------------
-Use one topic branch per pull request. If you do that, you can add extra commits or fix up
-buggy commits via `git rebase -i`, and update the branch. The updated branch will be
-visible in the same pull request. Therefore, you should not open a new pull request when
+Use one topic branch per pull request. If you do that, you can add extra commits or fix up
+buggy commits via `git rebase -i`, and update the branch. The updated branch will be
+visible in the same pull request. Therefore, you should not open a new pull request when
you have to fix your changes.
Do not commit to master in your fork.
@@ -39,65 +39,44 @@ Provide a clean branch without merge commits.
Tests
-----
-As a general rule, any behavioral change to rebar requires a test to go with it. If there's
-already a test case, you may have to modify that one. If there isn't a test case or a test
-suite, add a new test case or suite in `inttest/`. [retest](https://github.com/dizzyd/retest) based tests are preferred, but
-we also have EUnit tests in `test/`.
+As a general rule, any behavioral change to rebar requires a test to go with it. If there's
+already a test case, you may have to modify that one. If there isn't a test case or a test
+suite, add a new test case or suite in `test/`.
-Say you've added a new test case in `inttest/erlc`. To only execute the modified suite,
-you would do the following:
```sh
-# First we build rebar and its deps to also get `deps/retest/retest`
-$ make debug deps
-# Now we can test the modified erlc suite
-$ deps/retest/retest -v inttest/erlc
+$ ./bootstrap
+$ ./rebar3 ct
```
-To test EUnit tests, you would do:
-```sh
-$ make debug
-$ ./rebar -v eunit
-```
-
-You can also run `make test` to execute both EUnit and [retest](https://github.com/dizzyd/retest) tests as `make check` does.
-
Credit
------
-To give everyone proper credit in addition to the git history, please feel free to append
+To give everyone proper credit in addition to the git history, please feel free to append
your name to `THANKS` in your first contribution.
Committing your changes
-----------------------
-Please ensure that all commits pass all tests, and do not have extra Dialyzer warnings.
-To do that run `make check`. If you didn't build via `make debug` at first, the beam files in
-`ebin/` might be missing debug_info required for [xref](http://www.erlang.org/doc/man/xref.html)
-and [Dialyzer](http://www.erlang.org/doc/man/dialyzer.html), causing a test
-failure.
-If that happens, running `make clean` before running `make check` could solve the problem.
-If you change any of the files with known but safe to ignore Dialyzer warnings, you may
-have to adapt the line number(s) in [dialyzer_reference](dialyzer_reference). If you do that,
-do not remove the
-leading blank line.
+Please ensure that all commits pass all tests, and do not have extra Dialyzer warnings.
+To do that run `./rebar3 ct` and `./rebar3 as dialyze dialyzer`.
#### Structuring your commits
-Fixing a bug is one commit.
-Adding a feature is one commit.
-Adding two features is two commits.
+Fixing a bug is one commit.
+Adding a feature is one commit.
+Adding two features is two commits.
Two unrelated changes is two commits.
-If you fix a (buggy) commit, squash (`git rebase -i`) the changes as a fixup commit into
+If you fix a (buggy) commit, squash (`git rebase -i`) the changes as a fixup commit into
the original commit.
#### Writing Commit Messages
-It's important to write a proper commit title and description. The commit title must be
-at most 50 characters; it is the first line of the commit text. The second line of the
-commit text must be left blank. The third line and beyond is the commit message. You
-should write a commit message. If you do, wrap all lines at 72 characters. You should
-explain what the commit does, what references you used, and any other information
+It's important to write a proper commit title and description. The commit title must be
+at most 50 characters; it is the first line of the commit text. The second line of the
+commit text must be left blank. The third line and beyond is the commit message. You
+should write a commit message. If you do, wrap all lines at 72 characters. You should
+explain what the commit does, what references you used, and any other information
that helps understanding your changes.
Basically, structure your commit message like this:
diff --git a/README.md b/README.md
index 075b841..27865f2 100644
--- a/README.md
+++ b/README.md
@@ -11,21 +11,13 @@ embed directly in a project. Where possible, rebar uses standard Erlang/OTP
conventions for project structures, thus minimizing the amount of build
configuration work. rebar also provides dependency management, enabling
application writers to easily re-use common libraries from a variety of
-locations (git, hg, etc).
+locations ([hex.pm](http://hex.pm), git, hg, etc).
-3.0 Alpha-6
+3.0 Beta-1
====
[DOCUMENTATION](http://www.rebar3.org/v3.0/docs)
-This is a preliminary branch, considered to be alpha, and still
-very unstable. Use at your own risk, but please do report bugs
-and issues encountered and we'll try to resolve problems as
-soon as possible.
-
-Compatibility with rebar 2.0 has been broken, and features removed to
-limit scope.
-
### Commands
| Command | Description |
@@ -144,7 +136,6 @@ $ ./rebar3 escriptize
$ _build/default/bin/rebar3
```
-
Contributing to rebar
=====================
diff --git a/src/rebar.app.src b/src/rebar.app.src
index 5abb643..e5d56bb 100644
--- a/src/rebar.app.src
+++ b/src/rebar.app.src
@@ -3,7 +3,7 @@
{application, rebar,
[{description, "Rebar: Erlang Build Tool"},
- {vsn, "3.0.0-alpha-6"},
+ {vsn, "3.0.0-beta-1"},
{modules, []},
{registered, []},
{applications, [kernel,