Skip to content
Merged
Changes from 4 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
47 changes: 46 additions & 1 deletion README.adoc
Original file line number Diff line number Diff line change
@@ -1,5 +1,14 @@
= Neo4j Cypher Manual

This page covers the following topics:

* xref:README.adoc#build-locally[]
* xref:README.adoc#raise-prs[]
* xref:README.adoc#documenting-changes[]
* xref:README.adoc#cypher-gql[]


[[build-locally]]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure these have to be set
asciidoc generates anchors for headings by default - it should be #building-locally for the line below

edit: just noticed, on github, both anchors are present now (eg https://github.com/JPryce-Aklundh/docs-cypher/tree/updated_readme?tab=readme-ov-file#documenting-changes and https://github.com/JPryce-Aklundh/docs-cypher/tree/updated_readme?tab=readme-ov-file#documenting-changes-to-cypher)

== Building locally

=== Prereqs
Expand Down Expand Up @@ -39,7 +48,7 @@ When you run `npm start`, the project is monitored for updates to asciidoc files

If a change to an asciidoc file is detected, the site is automatically rebuilt.


[[raise-prs]]
== Raising PRs


Expand Down Expand Up @@ -68,3 +77,39 @@ There are a few edge cases where we might want to work only on the current branc
** Create a feature branch from `dev`, to be merged into `dev` when appropriate.
* 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.
* Updates merged into the `dev` branch for the next release are cherry-picked into the `5.x` branch.

[[documenting-changes]]
== Documenting changes to Cypher

New, updated, deprecated, and removed features must be recorded on the xref:deprecations-additions-removals-compatibility.adoc[] page.

New and deprecated features should also be marked with a label:

* If the impacted feature has its own header in the Cypher Manual, use the following:

[role=label--new-5.x]
\== Header
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


[role=label--deprecated]
\== Header
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here too


* If the impacted feature is documented within a table (such as a return column in a `SHOW` command), use the following:

`featureX` label:new[Introduced in 5.x] +
`featureY` label:deprecated[]
Comment on lines +102 to +103
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these work, but i guess they could use a source block as well


Labels can be difficult to apply to updated features.
In these cases, it is often preferable to note the change in a sentence.
For example: "As of Neo4j 5.x, featureX supports ..."

Removed features should be removed from the Cypher Manual.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a fan of imperative mood for this (usually shorter)
"remove removed ..." isn't exactly elegant though :D


[[cypher-gql]]
== Cypher and GQL

When documenting a new Cypher feature, its relationship with GQL must be considered:

* If the feature is part of GQL's mandatory features, it should be recorded on the page xref:modules/ROOT/pages/appendix/gql-conformance/supported-mandatory.adoc[].
* If the feature is part of GQL's optional features, it should be recorded on the page xref:modules/ROOT/pages/appendix/gql-conformance/supported-optional.adoc[].
* if the feature adds functionality for which there exists an analogous GQL equivalent, it should be recorded on the page xref:modules/ROOT/pages/appendix/gql-conformance/analogous-cypher.adoc[].
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"analogous GQL equivalent" - is it analogous or equivalent? their use might be synonymous in this context, but then we only need one 🤔

* If the feature adds functionality for which there exists no GQL equivalent, it should be recorded on the page xref:modules/ROOT/pages/appendix/gql-conformance/additional-cypher.adoc[].