See also Release process for details about the release process.
The branches from the main erlide repository.
master
This branch points to the latest stable released version of erlide. It will never be rebased.
All new feature branches should be branched from master
.
pu
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
present in master
yet.
release
This is a temporary branch that is used to prepare a release. It is then
merged into 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 pu
instead.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 master
or next
. Please don’t merge pu
repeatedly,
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!