You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.adoc
+6-5Lines changed: 6 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -48,7 +48,8 @@ If a change to an asciidoc file is detected, the site is automatically rebuilt.
48
48
The docs-cypher repo (and all CoreDB docs repos) will contain the following branches:
49
49
50
50
* `4.4` - Long term support
51
-
* `5.x` - this is the currently published version, and therefore is the branch that we publish all v5 docs from.
51
+
* `5.x` - Long term support.
52
+
* `cypher-25` - this is the currently published version, and therefore is the branch that we publish all Cypher 25 docs from.
52
53
** PRs merged into this branch will be published live immediately.
53
54
* `dev` - this is always the next release - this branch will be published on the staging server, as a preview, but we will never publish from this branch publicly.
54
55
** Next means the “next version of documentation”, and may not mirror other Neo4j engineering repos.
@@ -60,11 +61,11 @@ Within Github we’ll update the branch descriptions with what the current and n
60
61
61
62
Here is the workflow for creating PRs in the repo, and our publication process:
62
63
63
-
* For any work on the **current** version, all work should be raised & merged against the `dev` branch, and cherry-picked back to `5.x` branch.
64
+
* For any work on the **current** version, all work should be raised & merged against the `dev` branch, and cherry-picked back to `cypher-25` branch.
64
65
There are a few edge cases where we might want to work only on the current branch, for example adding a warning that is not needed in the next version - this is ok!
65
66
* For content relating to the **next** release, raise PRs against the dev branch and use labels to mark the specific version it is targeting.
66
67
* For work on **next+n** docs (i.e a version beyond **next**), we have 2 options:
67
-
** Open a draft PR against `dev`, with a label for the specific version it is targeting - this can be shared & reviewed in draft mode, but will not be mergeable until it is pointed at the next release.
68
+
** Open a draft PR against `dev`, with a label for the specific server version it is targeting (e.g. `2025.01` ) - this can be shared & reviewed in draft mode, but will not be mergeable until it is pointed at the next release.
68
69
** Create a feature branch from `dev`, to be merged into `dev` when appropriate.
69
-
* When a new version is ready to published, the `5.x` branch will get a git tag, named with the exact version (for example, **5.1.0**), signifying that this point-in-time marks the completion of the work for that minor release.
70
-
* Updates merged into the `dev` branch for the next release are cherry-picked into the `5.x` branch.
70
+
* When a new version is ready to published, the `cypher-25` branch will get a git tag, named with the exact version (for example, **2025.01.00**), signifying that this point-in-time marks the completion of the work for that minor release.
71
+
* Updates merged into the `dev` branch for the next release are cherry-picked into the `cypher-25` branch.
0 commit comments