docs: Point at the current release

README.md

@@ -166,7 +166,7 @@ We strongly recommend read our [Modifying This Platform](modifying-platform.md)
 
 - [Heading for the Yocto Project](https://github.com/CollaborativeWritersHub/heading-for-the-yocto-project/releases/download/18.10.0/Heading-for-the-Yocto-Project.pdf)
 - [Embedded Linux Development using Yocto Projects - Third Edition](https://www.amazon.com.br/dp/B0BRCTY345/)
-- [Yocto Project Reference Manual](https://www.yoctoproject.org/docs/3.1/ref-manual/ref-manual.html#detailed-supported-distros)
+- [Yocto Project Reference Manual](https://docs.yoctoproject.org/ref-manual/index.html)
 
 ## Get in touch
 

modifying-platform.md

@@ -9,7 +9,26 @@ Manifests are inherently version controlled, since they are kept within a Git re
 
 This is an example of Repo manifest:
 
-![](sources/platform-readme-manifest.png)
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<manifest>
+  <remote fetch="https://github.com" name="github"/>
+
+  <!-- ### Yocto Project release used as default for all included layers and components ### -->
+  <default revision="master"/>
+
+  <!-- ### O.S. Systems Embedded Linux Core layers ### -->
+  <project remote="github" revision="master" name="openembedded/bitbake" path="sources/bitbake"/>
+  <project remote="github" name="openembedded/openembedded-core" path="sources/openembedded-core"/>
+
+  <project remote="github" name="OSSystemsEmbeddedLinux/meta-ossystems-base" path="sources/meta-ossystems-base"/>
+  <project remote="github" name="OSSystemsEmbeddedLinux/ossystems-yocto-base-scripts" path="sources/base">
+    <copyfile dest="setup-environment" src="setup-environment"/>
+  </project>
+
+  <project remote="github" revision="master" name="OSSystemsEmbeddedLinux/ye" path="sources/ye"/>
+</manifest>
+```
 
 As you can see, it's a simple markup file. Basically it defines the remotes which will be pulled by **Repo**, the name of the repositories **(which in Repo syntax it's called  "project")**, the revision and the destiny path. 
 
@@ -32,7 +51,7 @@ Each element describes a single Git repository to be cloned into the repo client
 
 ### Element default
 
-Its remote and revision attributes are used as default when a project element does not specify its own remote or revision attribute. In the example above, the default revision is `kirkstone`, so all projects which doesn't specify a revision will be fetched from **kirkstone** revision.
+Its remote and revision attributes are used as default when a project element does not specify its own remote or revision attribute. In the example above, the default revision is `master`, so all projects which doesn't specify a revision will be fetched from the **master** revision.
 
 ### Element copyfile
 
@@ -55,7 +74,7 @@ Now we'll add the element `project`:
 <project remote="github" revision="master" name="MyOrganization/meta-example" path="sources/meta-example"/>
 ```
 
-So we'll add a remote called `github`, that we declared on `remote` element. The revision will be set to `master`, as the default revision of the manifest is `kirkstone`. The path to the organization and repository is `MyOrganization/meta-example`. Finally, the path destination is `source/meta-example`, where the `meta-example` will be cloned.
+So we'll add a remote called `github`, that we declared on `remote` element. The revision is set to `master` explicitly; without it, the project would follow the manifest's default revision. The path to the organization and repository is `MyOrganization/meta-example`. Finally, the path destination is `source/meta-example`, where the `meta-example` will be cloned.
 So, when Repo parse it, it will clone from `https://github.com/MyOrganization/meta-example` into `source/meta-example` directory.
 
 ### Adding a layer to setup-environment