From 073df2b8734ff2f0b34aa5ef8990137f6ea32feb Mon Sep 17 00:00:00 2001 From: David Gardiner Date: Wed, 16 Oct 2024 10:28:40 +1030 Subject: [PATCH] Add link to version number normalisation page --- src/content/docs/en-us/create/create-packages.mdx | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/content/docs/en-us/create/create-packages.mdx b/src/content/docs/en-us/create/create-packages.mdx index 7a1f2cfb309..bb2e63627c1 100644 --- a/src/content/docs/en-us/create/create-packages.mdx +++ b/src/content/docs/en-us/create/create-packages.mdx @@ -363,6 +363,8 @@ Versioning can be both simple and complicated. The best recommendation is to use If the 4th segment is used, some folks like to drop the segment altogether and use that as only the package fix notation using one of the notations in the next section. There is no recommendations at this time. +See also . + ### Package Fix Version Notation Package fix version notation ONLY applies when you are making a fix to the package because the existing version of a package is incorrect in some way. So if the software is `1.1.0`, in a normal scenario the package version should be `1.1.0`. If you find that the `1.1.0` package has an issue and you need to fix the package but keep the same version of the software, that is where package fix version notation comes into play. You would end up with both a `1.1.0` package and a `1.1.0.YYYYMMDD` version of the package.