See also Release process for details about the release process.
The branches from the main erlide repository.
This branch points to the latest stable released version of erlide. It will never be rebased.
All new feature branches should be branched from
This is the current development branch. It includes all fixes and new features that we plan to include in the next release.
Here we gather all the proposed updates, so that they can be tested and
evaluated before they are include in
master. It may be rebased, don’t
base any topic branches on it unless you need fixes/features that aren’t
This is a temporary branch that is used to prepare a release. It is then
master and deleted.
These branches are those in your repository where the work is done and where the result can be merged into the main branches.
Branches that fix a bug that has an issue on the ticket tracker should have a name that starts with that bug’s id and an underscore. We would like that the rest of the name describes the issue. This helps a lot with having updated changelogs.
Creating new feature for erlide usually means that you will spend some time working on it. When your job is done you will have to ask to merge it into erlide’s repository. So here is how you should start:
next. See above for when it is a good idea to use
While developing your feature you should keep up-to-date with erlide’s
code (there maybe some changes which will impact your code or make it
very difficult to merge into
pu when your work is done). This can be
done by merging
next. Please don’t merge
as it may get rebased. Merging
pu (or rebasing on top of it) should be
done only when you are done with your feature and want to make sure the
merge to upstream will be painless (for which I will be very grateful!).
The same workflow applies for bugfixes too.
Did you find errors in the documentation? Do you have improvements to suggest? Suggest edits!