Each main development series (like 0.2.1, 0.2.2, etc) has its main work
applied to a single branch. At most one series can be the development series
at a time; all other series are maintenance series that get bug-fixes only.
-The development series is built in a git branch called "master"; the
+The development series is built in a git branch called "main"; the
maintenance series are built in branches called "maint-0.2.0", "maint-0.2.1",
and so on. We regularly merge the active maint branches forward.
base your bugfix branch on the "maint" branch for the first supported series
that has that bug. (As of June 2013, we're supporting 0.2.3 and later.)
-If you're working on a new feature, base it on the master branch. If you're
+If you're working on a new feature, base it on the main branch. If you're
working on a new feature and it will take a while to implement and/or you'd
like to avoid the possibility of unrelated bugs in Tor while you're
implementing your feature, consider branching off of the latest maint- branch.
$ git clone https://git.torproject.org/git/tor
```
- This will give you a checkout of the master branch. If you're
+ This will give you a checkout of the main branch. If you're
going to fix a bug that appears in a stable version, check out the
appropriate "maint" branch, as in:
It's CI/builders. Looks like this: https://jenkins.torproject.org
Runs automatically on commits merged to git.torproject.org. We CI the
-master branch and all supported tor versions. We also build nightly debian
-packages from master.
+main branch and all supported tor versions. We also build nightly debian
+packages from main.
Builds Linux and Windows cross-compilation. Runs Linux tests.
responsibilities. Tor has one main single maintainer but does have many
committers and subsystem maintainers.
-The second third section describes how the **alpha and master** branches are
+The second third section describes how the **alpha and main** branches are
maintained and by whom.
Finally, the last section describes how the **stable** branches are maintained
## Alpha and Master Branches
-The Tor repository always has at all times a **master** branch which contains
+The Tor repository always has at all times a **main** branch which contains
the upstream ongoing development.
It may also contain a branch for a released feature freezed version which is
developers than the main maintainer. Those people have commit access to the
code base but only commit (in most cases) into the subsystem they maintain.
-Upstream merges are restricted to the alpha and master branches. Subsystem
+Upstream merges are restricted to the alpha and main branches. Subsystem
maintainers should never push a patch into a stable branch which is the
responsibility of the [stable branch maintainer](#stable-branches).
These are the tasks of a subsystem maintainer:
1. Regularly go over `merge_ready` tickets relevant to the related subsystem
- and for the current alpha or development (master branch) Milestone.
+ and for the current alpha or development (main branch) Milestone.
2. A subsystem maintainer is expected to contribute to any design changes
(including proposals) or large patch set about the subsystem.
4. Tor uses the "merge forward" method, that is, if a patch applies to the
alpha branch, it has to be merged there first and then merged forward
- into master.
+ into main.
5. Maintainer should always consult with the network team about any doubts,
mis-understandings or unknowns of a patch. Final word will always go to the
(Ideally, do this immediately after a release.)
-1. Start a new maint-x.y.z branch based on master, and a new
- release-x.y.z branch based on master. They should have the same
+1. Start a new maint-x.y.z branch based on main, and a new
+ release-x.y.z branch based on main. They should have the same
starting point.
- Push both of these branches to the master git repository.
+ Push both of these branches to the canonical git repository.
-2. In master, change the version to "0.x.y.0-alpha-dev". Run the
+2. In the main branch, change the version to "0.x.y.0-alpha-dev". Run the
update_versions.py script, and commit this version bump.
3. Tag the version bump with "tor-0.x.y.0-alpha-dev". Push the tag
- and master.
+ and main branch.
4. Open tickets for connecting the new branches to various other
places. See section 2 above for a list of affected locations.
target in the maint-x.y.z branch only.
* Delete the file scripts/maint/practracker/.enable_practracker_in_hooks
in the maint-x.y.z branch only.
- * Merge to release-x.y.z, but do not forward-port to master.
+ * Merge to release-x.y.z, but do not forward-port to the main branch.
6. Finally, make sure this document is up to date with our latest
process.
note added to each section. So in this case, once you have the items
from the changes files copied together, don't use them to build a new
changelog: instead, look up the corrected versions that were merged
- into ChangeLog in the master branch, and use those.
+ into ChangeLog in the main branch, and use those.
Add "backport from X.Y.Z" in the section header for these entries.
places, and commit. Then merge `maint-0.?.x` into `release-0.?.x`.
When you merge the maint branch forward to the next maint branch, or into
- master, merge it with "-s ours" to avoid conflict with the version
+ main, merge it with "-s ours" to avoid conflict with the version
bump.
2. Make distcheck, put the tarball up in somewhere (how about your
1. If it's a stable release, bump the version number in the
`maint-x.y.z` branch to "newversion-dev", and do a `merge -s ours`
- merge to avoid taking that change into master.
+ merge to avoid taking that change into main.
2. If there is a new `maint-x.y.z` branch, create a Travis CI cron job that
builds the release every week. (It's ok to skip the weekly build if the
branch was updated in the last 24 hours.)
3. Forward-port the ChangeLog (and ReleaseNotes if appropriate) to the
- master branch.
+ main branch.
4. Keep an eye on the blog post, to moderate comments and answer questions.
# requires perl 5.8. Avoids shell issues if we ever get a changes
# file named by the parents of Little Johnny Tables.
open F, "-|", "git", "log", "--no-merges", "--pretty=format:%H", $branches, "--", $fname
- or die "$!";
+ or die "$!";
my @changes = <F>;
return scalar @changes
}
findMergedChanges.pl [--merged/--unmerged/--weird/--list] [--branch=<branchname] [--head=<branchname>] changes/*
A change is "merged" if it has ever been merged to release-0.2.4 and it has had
-no subsequent changes in master.
+no subsequent changes in main.
A change is "unmerged" if it has never been merged to release-0.2.4 and it
-has had changes in master.
+has had changes in main.
A change is "weird" if it has been merged to release-0.2.4 and it *has* had
-subsequent changes in master.
+subsequent changes in main.
Suggested application:
findMergedChanges.pl --merged changes/* | xargs -n 1 git rm
}
my $target_branch = "origin/release-0.2.4";
-my $head = "origin/master";
+my $head = "origin/main";
while (@ARGV and $ARGV[0] =~ /^--/) {
my $flag = shift @ARGV;
if ($flag =~ /^--(weird|merged|unmerged|list)/) {
- $look_for_type = $1;
+ $look_for_type = $1;
} elsif ($flag =~ /^--branch=(\S+)/) {
$target_branch = $1;
} elsif ($flag =~ /^--head=(\S+)/) {
$head = $1;
} else {
- die "Unrecognized flag $flag";
+ die "Unrecognized flag $flag";
}
}
my $type;
if ($n_merged != 0 and $n_postmerged == 0) {
- $type = "merged";
+ $type = "merged";
} elsif ($n_merged == 0 and $n_postmerged != 0) {
- $type = "unmerged";
+ $type = "unmerged";
} else {
- $type = "weird";
+ $type = "weird";
}
if ($type eq $look_for_type) {
- print "$changefile\n";
+ print "$changefile\n";
} elsif ($look_for_type eq 'list') {
- printf "% 8s: %s\n", $type, $changefile;
+ printf "% 8s: %s\n", $type, $changefile;
}
}
projects / thirdparty / tor.git / commitdiff
