Modified release doc.

Author: jcpitre

README.md

@@ -63,7 +63,7 @@ To facilitate easier debugging and logging, we have made our user agent header e
 ### Run it
 Once installed, run the application and you will see the following screen:
 
-![Application-Windows](/docs/Application-Windows.png)
+![Application-Windows](/docs/images/Application-Windows.png)
 
 There are two primary options to set:
 

build.gradle

@@ -41,7 +41,7 @@ allprojects {
 
     // Per the axion-release plugin, this computes the project version based
     // on the most recent tag in the repo.
-    version "7.1.1"
+    version scmVersion.version
 
     repositories {
         mavenCentral()

docs/ACCEPTANCE_TESTS.md

@@ -102,7 +102,7 @@ The source id can be used to find all datasets versions of a source on the [Mobi
 ## What do we do with the results?
 We follow this process:
 
-<img src="/docs/Acceptance-test-process.jpg" width="750">
+<img src="/docs/images/Acceptance-test-process.jpg" width="750">
 
 ## Performance metrics within the acceptance reports
 

docs/BRANCHING.md

@@ -16,7 +16,7 @@
   - A maintenance is created if some bug has to be corrected before the next scheduled release.
     - As an example see [#1663](https://github.com/MobilityData/gtfs-validator/pull/1653) in the gtfs-validator repository.
 
-![](BranchingDiagram.png)
+![](images/BranchingDiagram.png)
 
 ## Feature/fix branches
 

docs/CONTRIBUTING.md

@@ -88,7 +88,7 @@ This process is described in more detail in the GitHub documentation [**Contribu
 
 This image shows the tests implemented in the Pull Request process.
 
-<img src="/docs/Pull-Request-process.jpg" width="700">
+<img src="/docs/images/Pull-Request-process.jpg" width="700">
 
 ## Pull Request comments and reviews
 Reviewing Pull Requests is a great way to get familiar with the code & architecture of this tool, and to make sure a functionality meets your needs. Each Pull Request has to be approved by at least one one core developer, but having community members helping with this process is significant for the MobilityData team. Additionally, having the eyes of people from different expertise and backgrounds on a contribution makes it higher quality (nobody can think of everything!).
@@ -131,7 +131,7 @@ A critical step in troubleshooting is being able to reproduce the problem. Instr
 
 The acceptance test is a key part of the Pull Request process. More information about this test is available in the [ACCEPTANCE_TEST.md](/docs/ACCEPTANCE_TESTS.md) file.
 
-<img src="/docs/Acceptance-test-process.jpg" width="650">
+<img src="/docs/images/Acceptance-test-process.jpg" width="650">
 
 **How to run tests locally?**
 

docs/RELEASE.md

@@ -63,25 +63,20 @@ Uploaded artefacts have versions.
 
 * Typically when doing a release the publish_assets.yml Github action is automatically run. 
 This will upload some assets
-to be available on the release page itself (see for example [Release 4.1.0 assets](https://github.com/MobilityData/gtfs-validator/releases/tag/v4.1.0#:~:text=7%20other%20contributors-,Assets,-6))
+to be available on the release page itself (see for example [Release 7.1.0 assets](https://github.com/MobilityData/gtfs-validator/releases/tag/v7.1.0))
 
 
-* This Github action also publishes to Sonatype. This is used as a staging area before making the arftefacts available via Maven Central. 
-* See [Sonatype Staging Repositories](https://s01.oss.sonatype.org/#stagingRepositories) (login required)
-* There should be a repository in the list with name orgmobilitydata-####. This is automatically created by Sonatype when files are uploaded.
+* This Github action also publishes to Maven Central. 
+* See [Maven Sentral Repository Deployments](https://central.sonatype.com/publishing/deployments) (login required)
+* If the Github action was successful, there should be components in this page:
 
-![image](https://github.com/MobilityData/gtfs-validator/assets/106176106/f08a24ec-addb-4d63-840d-24297c505822)
+![image](images/Maven-central-deployments.png)
 
-
-* You can browse the repo content to make sure everything is there. In particular there should be the jars for the code, jars for javadoc, for sources, and files for the maven pom. 
+* You can browse the different components, look at the components files, make sure the version is correct, etc.
 * Everything should be signed, as evidenced by the presence of files with extension .sha1, .sha256, .sha512 etc.
-* Also make sure the version is correct.
-* You then need to manually close the repo. Doing this will trigger acceptance tests for Maven Central.
-
-![image](https://github.com/MobilityData/gtfs-validator/assets/106176106/1d8916c6-a640-43cf-9658-82193d127b1d)
-
-* Once the repository is closed it becomes available for inclusion in projects for testing. The URL to use as repository in your gradle or maven configuration files can be found in the summary for the repo.
-![image](https://github.com/MobilityData/gtfs-validator/assets/106176106/c809c1ca-67d7-4c45-bfa5-47441e163d2f)
+* If for some reason you think the components should not be published, you can press the `Drop` button for each component.
+* If you are satisfied, you can press the `Publish` button for each of the components. 
+* The result should be that the components are made available in Maven Central. See [Maven Central Repository](https://repo1.maven.org/maven2/org/mobilitydata/gtfs-validator/) for the published components.
+* They will disappear from the page as you publish or drop them.
 
-* Once satisfied with the testing, the repo can be released to Maven Central.
-* Note that once a release is deployed on Maven Central, it cannot be removed or modified. If problems are detected after this stage, a new release with a different version has to be created.
+* Note that once a release is published on Maven Central, it cannot be removed or modified. If problems are detected after this stage, a new release with a different version has to be created.