website: updates

website/docs/developer/index.mdx

@@ -56,7 +56,7 @@ for inexperienced users.
 <details>
 <summary>xPack build configurations</summary>
 
-The xPack framework supports projects with **multiple build configurations**.
+The xPack Framework supports projects with **multiple build configurations**.
 
 Build configurations are sets of **properties**, **actions** and **dependencies**
 that apply to a specific build. Build configurations can inherit from
@@ -65,7 +65,7 @@ other build configurations.
 For simple projects, the typical use case is with two configurations,
 **Debug** and **Release**.
 
-For building the xPack binary tools, there is one configuration
+For building the binary xPack executables, there is one configuration
 for each platform:
 
 

website/docs/getting-started/index.mdx

@@ -55,40 +55,57 @@ this project also includes the
 
 ## xPacks
 
+**xPacks** (short for **xpm packages**) are general-purpose,
+language-neutral software packages.
+
 <details>
-<summary>What the heck are xPacks? Please, not yet another package format!</summary>
+<summary>What the heck are xPacks? Please, do not introduce another package format!</summary>
+
+While the initial appearance may seem complex, utilizing xPacks
+(xpm packages) is, in fact, straightforward.
+The design rationale is to automate frequent
+operations that occur during software development, in this case the
+installation of
+dependencies, and to ensure reproducibility.
+
+xPacks are managed by **[xpm](https://xpack.github.io/xpm/)**
+(the xPack Project Manager),
+a program that complements the **[npm](https://docs.npmjs.com/cli/)** CLI
+(the popular JavaScript package manager), with new language-neutral features.
+
+The xPacks Framework **does NOT introduce a new package format**; instead,
+it uses **the same format as npm packages**, which is a collection of
+files/folders and a `package.json` file with the package metadata.
 
-**xPacks** are general purpose multi-version software packages.
+**xpm** can install packages from the
+same repositories as **npm**, whether public or private.
 
-There are two types of xPacks:
+The packages (usually regular archives, but also git repositories),
+are extracted into separate folders within the project.
+
+Based on the content, there are two types of packets:
 
 - **source xPacks** (that install source files, usually libraries) and
 - **binary xPacks** (that install executables/binary files, usually tools).
 
-The xPacks project **does NOT introduce a new package format**; instead,
-it uses **the same format as npm**, which is a collection of files/folders
-and a `package.json` file with the package metadata. Additionally,
-installing binary xPacks also installs the archives with the platform specific
+The binary xPacks include references to archives with the platform specific
 binaries (such as `.tar.gz` for Unix or `.zip` for Windows).
 
-Also, xPacks can be installed from the
-same repositories as **npm** packages, whether public or private.
+These archives are also expanded along the package metadata. Since they
+include executables, links/forwarders to
+these executables are created in a `.bin` folder,
+eliminating the need to add multiple folders to the `PATH`.
 
-xPacks are managed by **[xpm](https://xpack.github.io/xpm/)**
-(the xPack Project Manager),
-a program that complements the **[npm](https://docs.npmjs.com/cli/)** CLI (the
-popular JavaScript package manager),
-with new language-neutral features.
+Given that some binary xPacks, such as toolchains, can have very large
+archives, the packages are extracted only once into a user global location to
+conserve space. In projects, instead of duplicating the content of these
+archives, symbolic links are created.
 
-There is no magic behind **xpm**, it operates straightforwardly by
-unpacking platform-specific archives into distinct directories and then creating links in the project to the corresponding executables.
-
-In short, xPacks are just a way to automate installing source libraries and
-tools.
+Simply put, xPacks can be used to further automate the installation of source
+libraries and tools.
 
 </details>
 
-
 ## Features
 
 All binaries are:
@@ -131,7 +148,7 @@ procedure; the same procedure is used for all major
 ## Install
 
 The executables and other related files can be installed automatically with
-**xpm** via the **binary xPacks** or manually by downloading the
+**xpm** or manually by downloading the
 **platform specific archives**.
 
 The details of installing the **xPack GNU Arm Embedded GCC** on various platforms are

website/docs/install/_common/_automatic-install-quick-test.mdx

@@ -43,3 +43,10 @@ ${props.branding}${customField('upstreamVersion')}
 </TabItem>
 
 </Tabs>
+
+:::note
+
+The reported version is the upstream version, which is shorter than the xPack
+version, as the latter requires more digits to identify the releases.
+
+:::

website/docs/install/_common/_manual-install-quick-test.mdx

@@ -43,3 +43,10 @@ ${props.branding}${customField('upstreamVersion')}
 </TabItem>
 
 </Tabs>
+
+:::note
+
+The reported version is the upstream version, which is shorter than the xPack
+version, as the latter requires more digits to identify the releases.
+
+:::

website/docs/install/index.mdx

@@ -41,29 +41,26 @@ platform specific archives.
 ## Automated install
 
 The easiest (and recommended) way to install GNU Arm Embedded GCC
-is by using the **binary xPack**, available
+is via **xpm** and the package available
 as <a href={`https://www.npmjs.com/package/@xpack-dev-tools/arm-none-eabi-gcc`}><code>@xpack-dev-tools/arm-none-eabi-gcc</code></a> from
 the [`npmjs.com`](https://www.npmjs.com) registry.
 
 <details>
-<summary>xPacks 101</summary>
+<summary>xPacks refresher</summary>
 
-While the initial appearance may seem complex, utilizing xPacks is,
-in fact, straightforward. The design rationale is to automate frequent
-operations that occur during software development, in this case the
-installation of
-dependencies, and to ensure reproducibility.
+xPacks (short for xpm packages) are general-purpose,
+language-neutral software packages.
+They use **the same format as npm packages**,
+which is a collection of files/folders
+and a `package.json` file with the package metadata.
 
-xPacks are regular archives that are extracted into separate folders
-within the project. If the xPacks contain
-executables, links/forwarders to
-these executables are created in a `.bin` folder,
-eliminating the need to add multiple folders to the `PATH`.
+Binary xPacks also include references to regular archives with the platform
+specific binaries (such as `.tar.gz` for Unix or `.zip` for Windows).
+These archives are unpacked and links/forwarders to
+the executables are created in a `.bin` folder.
 
-Given that some binary xPacks, such as toolchains, can be quite large,
-the archives are extracted only once into a user global location to
-conserve space. In projects, instead of duplicating the content of these
-archives, symbolic links are created.
+For more details, please see the previous explanation in the
+[Getting Started](/docs/getting-started/#xpacks) page.
 
 </details>
 
@@ -135,12 +132,12 @@ If multiple binary packages are installed, in order to allow
 the executables to be accessed, one possible solution is to add
 all `<package>/.content/bin` folders to the `PATH`.
 
-To simplify things, **npm** employs a separate `node_modules/.bin` folder
+To simplify things, **npm** employs a separate `<project>/node_modules/.bin` folder
 where it places links/forwarders
 pointing to the actual executable files.
 
 Similarly, **xpm** adds links/forwarders into
-a separate `xpacks/.bin` folder.
+a separate `<project>/xpacks/.bin` folder.
 
 With this setup, the project needs to prepend only this `.bin` folder
 to the `PATH`, and all the required tools are accesible
@@ -212,7 +209,7 @@ already present.
 
 In addition to `name` & `version`, the minimal `package.json` must
 include a property named `xpacks`, even empty. This property is
-mandatory to identify the package as an **xPack**.
+mandatory to identify the package as an **xpm package**.
 
 </details>
 
@@ -458,7 +455,7 @@ The binaries do not use any form of installer; instead they
 are distributed as
 portable {props.isWindows ? <code>.zip</code> : <code>.tar.gz</code>} archives;
 therefore they do not require to run any uninstaller; simply removing the
-links and possibly the user global xPack store folder and
+links and possibly the user global xPacks store folder and
 the user xPack cache folder is enough.
 
 To remove the <LinksVsForwarders isWindows={props.isWindows}/> created by
@@ -475,7 +472,7 @@ and ask **xpm** to uninstall the package:
 `xpm uninstall @xpack-dev-tools/arm-none-eabi-gcc --verbose
 `} </CodeBlock>
 
-To completely remove the package from the user global xPack store:
+To completely remove the package from the user global xPacks store:
 
 <CodeBlock language="sh"> {
 `xpm uninstall --global @xpack-dev-tools/arm-none-eabi-gcc --verbose
@@ -514,7 +511,7 @@ For a thorough clean-up, please note that **xpm** uses only two folders:
 They can be removed at any time and space reclaimed;
 **xpm** will recreate them on new installs.
 
-However, projects linking to the user global xPack store will fail with
+However, projects linking to the user global xPacks store will fail with
 broken paths.
 
 </details>

website/docs/maintainer/index.mdx

@@ -727,7 +727,7 @@ watching this project.
 
 ### Prepare a new blog post
 
-- check and possibly update the `build-assets/templates/body-blog-release-*-liquid.md`
+- check and possibly update the `website/blog/_templates/blog-post-release-part-[12]-liquid.md`
 - run the **generate-website-blog-post** xPack action;
 this will add a file in the `website/blog` folder:
 

website/docusaurus.config.ts

@@ -36,7 +36,7 @@ function getCustomFields() {
   const xpackVersion = jsonVersion.replace(/[.][0-9]*$/, '');
 
   // Remove the pre-release.
-  const xpackSemver = xpackVersion.replace(/[-][0-9]*$/, '');
+  const xpackSemver = xpackVersion.replace(/[-].*$/, '');
 
   // Remove the first part, up to the dash.
   const xpackSubversion = xpackVersion.replace(/^.*[-]/, '');

website/src/components/HomepageFeatures/index.tsx

@@ -38,7 +38,7 @@ const FeatureList: FeatureItem[] = [
     Svg: require('@site/static/img/check-badge.svg').default,
     description: (
       <>
-        The binary xPacks can be added to projects
+        The binary packages can be added to projects
         as <b>development dependencies</b>,
         and conveniently installed with <code>xpm install</code>.
         This feature also ensures reproducibility, which is particularly
@@ -55,7 +55,7 @@ const FeatureList: FeatureItem[] = [
         complements <b><Link to="https://docs.npmjs.com/cli/">npm</Link></b> with
         several extra features specific to <b>C/C++ projects</b>.
         This allows the
-        binary xPacks to nicely integrate into the Node.js ecosystem,
+        binary packages to nicely integrate into the Node.js ecosystem,
         while still allowing the binary archives to be installed manually.
       </>
     ),

website/src/pages/index.tsx

@@ -43,7 +43,7 @@ export default function Home(): JSX.Element {
   return (
     <Layout
       title={`Hello from xPack Binary Development Tools`}
-      description="A binary xPack with the GNU Arm Embedded GCC executables">
+      description="A binary package with the GNU Arm Embedded GCC executables">
       <HomepageHeader />
       <main>
         <HomepageFeatures />