Browse Source

update git workflow documentation

tags/v2.8.0-rc1
Shivaram Lingamneni 2 years ago
parent
commit
404bf6c2a0
2 changed files with 5 additions and 9 deletions
  1. 2
    4
      DEVELOPING.md
  2. 3
    5
      README.md

+ 2
- 4
DEVELOPING.md View File

@@ -18,11 +18,9 @@ If you're upgrading the Go version used by Ergo, there are several places where
18 18
 
19 19
 ## Branches
20 20
 
21
-The `master` branch should be kept relatively runnable. It might be a bit broken or contain some bad commits now and then, but the pre-release checks should weed those out before users see them.
21
+The recommended workflow for development is to create a new branch starting from the current `master`. Even though `master` is not recommended for production use, we strive to keep it in a usable state. Starting from `master` increases the likelihood that your patches will be accepted.
22 22
 
23
-For either particularly broken or particularly WiP changes, we work on them in a `develop` branch. The normal branch naming is `develop+feature[.version]`. For example, when first developing 'cloaking', you may use the branch `develop+cloaks`. If you need to create a new branch to work on it (a second version of the implementation, for example), you could use `develop+cloaks.2`, and so on.
24
-
25
-Develop branches are either used to work out implementation details in preperation for a cleaned-up version, for half-written ideas we want to continue persuing, or for stuff that we just don't want on `master` yet for whatever reason.
23
+Long-running feature branches that aren't ready for merge into `master` may be maintained under a `devel+` prefix, e.g. `devel+metadata` for a feature branch implementing the IRCv3 METADATA extension.
26 24
 
27 25
 
28 26
 ## Updating dependencies

+ 3
- 5
README.md View File

@@ -75,13 +75,11 @@ to Docker Hub at [ergochat/ergo](https://hub.docker.com/r/ergochat/ergo). For mo
75 75
 
76 76
 ### From Source
77 77
 
78
-You can also install this repo and use that instead! However, keep some things in mind if you go that way:
78
+You can also clone this repository and build from source. Typical deployments should use the `stable` branch, which points to the latest stable release. In general, `stable` should coincide with the latest published tag that is not designated as a beta or release candidate (for example, `v2.7.0-rc1` was an unstable release candidate and `v2.7.0` was the corresponding stable release), so you can also identify the latest stable release tag on the [releases page](https://github.com/ergochat/ergo/releases) and build that.
79 79
 
80
-`devel` branches are intentionally unstable, containing fixes that may not work, and they may be rebased or reworked extensively.
80
+The `master` branch is not recommended for production use since it may contain bugs, and because the forwards compatibility guarantees for the config file and the database that apply to releases do not apply to master. That is to say, running master may result in changes to your database that end up being incompatible with future versions of Ergo.
81 81
 
82
-The `master` branch _should_ usually be stable, but may contain database changes that either have not been finalised or not had database upgrade code written yet. Don't run `master` on a live production network.
83
-
84
-The `stable` branch contains the latest release, suitable for use in production.
82
+For information on contributing to Ergo, see [DEVELOPING.md](https://github.com/ergochat/ergo/blob/master/DEVELOPING.md).
85 83
 
86 84
 #### Building
87 85
 

Loading…
Cancel
Save