chore: Reverted back to gitversion

.github/workflows/publish-packages.yml

@@ -40,7 +40,7 @@ jobs:
         run: yarn
 
       - name: Bump
-        run: yarn gitbump bump $BUMP_TYPE
+        run: yarn gitversion bump $BUMP_TYPE
 
       - name: Build 🔧
         run: yarn build:all
@@ -53,7 +53,7 @@ jobs:
       #     aws-region: eu-west-1
 
       - name: Publish
-        run: yarn gitbump publish
+        run: yarn gitversion publish
         env:
           YARN_NPM_AUTH_TOKEN: ${{ secrets.NPM_AUTH_TOKEN }}
 

.gitignore

@@ -12,7 +12,7 @@
 #!.yarn/cache
 .pnp.*
 coverage
-gitbump.out
+gitversion.out
 lib
 tsconfig.tsbuildinfo
 

.gitbump.cjs → .gitversion.cjs

@@ -1,4 +1,4 @@
-const { defineConfig } = require('gitbump');
+const { defineConfig } = require('gitversion');
 
 module.exports = defineConfig({
   independentVersioning: false,
@@ -8,8 +8,8 @@ module.exports = defineConfig({
     //   bucketName: 'www-cputils-com-website-docspublishbucket31a61f6d-pixklxvi0wye',
     //   baseFolder: 'docs',
     //   fileNameTemplate: [
-    //     'gitbump/{version.major}.{version.minor}.x.zip',
-    //     'gitbump/{releaseChannel}.zip',
+    //     'gitversion/{version.major}.{version.minor}.x.zip',
+    //     'gitversion/{releaseChannel}.zip',
     //   ],
     //   exclude: [
     //     ".vitepress",

CONTRIBUTION.md

@@ -1,8 +1,8 @@
-# Contributing to gitbump
+# Contributing to gitversion
 
-Nice of you to join te gitbump repository. In order to get started I'd like to explain the basic setups of the repo
+Nice of you to join te gitversion repository. In order to get started I'd like to explain the basic setups of the repo
 
-You can read about the way gitbump works at [the documentation site](https://www.cp-utils.com/projects/gitversion/).
+You can read about the way gitversion works at [the documentation site](https://www.cp-utils.com/projects/gitversion/).
 
 ## Getting started
 
@@ -18,11 +18,11 @@ $ yarn
 Verify if everything works as expected:
 
 ``` sh
-$ yarn gitbump check
-$ yarn gitbump bump
-$ yarn gitbump pack 
-$ yarn gitbump publish --dry-run
-$ yarn gitbump reset
+$ yarn gitversion check
+$ yarn gitversion bump
+$ yarn gitversion pack 
+$ yarn gitversion publish --dry-run
+$ yarn gitversion reset
 ```
 
 ## Repo setup
@@ -31,7 +31,7 @@ The repository setup has the following key elements:
 
 - [yarn 4 (berry) package manager](#yarn)
 - [Typescript only](#typescript)
-- [Gitbump release](#gitbump)
+- [Gitversion release](#gitversion)
 - [Jest based unit testing](#jest)
 - [Eslint linter](#eslint)
 
@@ -46,15 +46,15 @@ We also use yarn [constraints](https://yarnpkg.com/features/constraints) for con
 
 All source code in the repo is [typescript](https://www.typescriptlang.org/). The only exception for this are (small) configuration files. 
 
-There should never be any need to have any javascript available during development time. The only time we have javascript is during the pack command of the actual production package. You can see this in action in [workspaces/packages/gitbump/package.json](workspaces/packages/gitbump/package.json) where we have basically this:
+There should never be any need to have any javascript available during development time. The only time we have javascript is during the pack command of the actual production package. You can see this in action in [workspaces/packages/gitversion/package.json](workspaces/packages/gitversion/package.json) where we have basically this:
 
 ```json 
 "scripts": {
   "prepack": "tsc --noEmit false", // Execute typescript with the option to emit teh output before we pack
   "postpack": "rm -rf lib"         // Remove the generated files to cleanup the workspace
 }
 ```
-And we use this to be able to use gitbump itself in typescript mode:
+And we use this to be able to use gitversion itself in typescript mode:
 ```json
 "bin": "bin/index-typescript.js",
 "main": "src/index.ts",
@@ -66,9 +66,9 @@ And we use this to be able to use gitbump itself in typescript mode:
 },
 ```
 
-### Gitbump
+### Gitversion
 
-Of course we use gitbump itself in the repo. We use it in the default mode and execute it with the above helpers in combination with [ts-node](https://www.npmjs.com/package/ts-node)
+Of course we use gitversion itself in the repo. We use it in the default mode and execute it with the above helpers in combination with [ts-node](https://www.npmjs.com/package/ts-node)
 
 ### Jest
 

README.md

@@ -1,8 +1,8 @@
-# Gitbump
+# Gitversion
 
-Gitbump is a complete customizable git-based release management system. Primarily focused on package releases.
+Gitversion is a complete customizable git-based release management system. Primarily focused on package releases.
 
-![NPM Version](https://img.shields.io/npm/v/gitbump)
+![NPM Version](https://img.shields.io/npm/v/gitversion)
 
 ## Key concepts
 
@@ -17,9 +17,9 @@ Gitbump is a complete customizable git-based release management system. Primaril
 
 ### Branch based release strategy
 
-The core concept of gitbump evolves around branch detection and branch types.
+The core concept of gitversion evolves around branch detection and branch types.
 
-Gitbump defines the following types:
+Gitversion defines the following types:
 - main/master branch (default branch name **'main'**)
 - release branches (default matches **'release/*'**)
 - feature branches (default matches **'feature/*'**)
@@ -38,48 +38,48 @@ Depending on the detected branch types the system will make different choices:
 
 ### Tag based versioning
 
-Like most release systems gitbump will add a tag for each release. This will follow the tag naming with a prefix (default 'v'). I.e.
+Like most release systems gitversion will add a tag for each release. This will follow the tag naming with a prefix (default 'v'). I.e.
 
 - v1.0.0
 - v1.2.3-next.0
 
-The difference of gitbump is that the tags are the only source of truth. It does not care about versions inside files and will keep them even on the default "0.0.0".
+The difference of gitversion is that the tags are the only source of truth. It does not care about versions inside files and will keep them even on the default "0.0.0".
 
 There are two main advantages of this strategy:
 
 - One source of truth. Easy to see in git history what the current state is
 - No more merge conflicts due to mismatches of versions. Otherwise this will happen constantly with feature/release strategies
 
-Gitbump has 2 commands to work with this git-only version strategy:
+Gitversion has 2 commands to work with this git-only version strategy:
 
 #### Restore 
 ```bash
-yarn gitbump restore
+yarn gitversion restore
 ```
 
 The output will be something like:
 
-![gitbump restore](./assets/restore.png)
+![gitversion restore](./assets/restore.png)
 
 As you see with this you wil get all versions back in package.json files.
 
 #### Reset 
 ```bash
-yarn gitbump reset
+yarn gitversion reset
 ```
 
 The output will be something like:
 
-![gitbump reset](./assets/reset.png)
+![gitversion reset](./assets/reset.png)
 
 As you see with this you wil reset all versions back to '0.0.0'.
 
 ### Conventional commit based bumps
 
-Gitbump works with the concept of a "bump". This is one of the key commands:
+Gitversion works with the concept of a "bump". This is one of the key commands:
 
 ```bash
-yarn gitbump bump
+yarn gitversion bump
 ```
 
 Bump will do the following steps:
@@ -89,11 +89,11 @@ Bump will do the following steps:
 - Define a bump type based on the outcome
 - Update the workspaces with the new version
 - Udate the workspaces with the workspace specific changelogs
-- Create a bump manifest in the **gitbump.out** folder containing versions and changelogs
+- Create a bump manifest in the **gitversion.out** folder containing versions and changelogs
 
 ### Native monorepo support
 
-Gitbump is build for monorepos with multiple workspaces. It will detect all (public) workspaces and use them during bump.
+Gitversion is build for monorepos with multiple workspaces. It will detect all (public) workspaces and use them during bump.
 
 There are 2 main operation modes:
 - [global versioning](#Global-versioning)
@@ -109,7 +109,7 @@ This will use unique versions per workspace in the mono repo. Based on the path
 
 ### Split stage publish
 
-Gitbump is buld for usage within CI/CD pipelines. When building packages gitbump can be used in a pipeline like this:
+Gitversion is buld for usage within CI/CD pipelines. When building packages gitversion can be used in a pipeline like this:
 
 ![Pipeline](./assets/pipeline.png)
 

docs/.vitepress/config.mts

@@ -5,11 +5,11 @@ const sidebar = await import('../sidebar.mjs');
 
 // https://vitepress.dev/reference/site-config
 export default defineConfig({
-  title: 'Testing gitbump docs',
+  title: 'Testing gitversion docs',
   description: 'A VitePress Site',
   themeConfig: {
     nav: [
-      { text: 'Gitbump', link: '/tutorials/getting-started' },
+      { text: 'Gitversion', link: '/tutorials/getting-started' },
     ],
 
     sidebar: sidebar.sidebar,

docs/index.md

@@ -94,7 +94,7 @@ Bump will do the following steps:
 - Define a bump type based on the outcome
 - Update the workspaces with the new version
 - Udate the workspaces with the workspace specific changelogs
-- Create a bump manifest in the **gitbump.out** folder containing versions and changelogs
+- Create a bump manifest in the **gitversion.out** folder containing versions and changelogs
 
 ### Native workspace/monorepo support {#monorepo}
 

docs/reference/configuration.md

@@ -18,7 +18,7 @@ Gitversion currently searches for the following file:
 This has to be a commonjs file with the following basics:
 
 ```js
-const { defineConfig } = require("gitbump");
+const { defineConfig } = require("gitversion");
 
 module.exports = defineConfig({
   // configuration options
@@ -52,7 +52,7 @@ Changelogs are always generated on a per workspace base. Therefor independent ve
 
 ::: details Example .gitversion.cjs
 ```js
-const { defineConfig } = require("gitbump");
+const { defineConfig } = require("gitversion");
 
 module.exports = defineConfig({
   independentVersioning: true
@@ -83,7 +83,7 @@ See more about branch types in [working with branches](../how-to/working-with-br
 
 ::: details Example .gitversion.cjs
 ```js
-const { defineConfig } = require("gitbump");
+const { defineConfig } = require("gitversion");
 
 module.exports = defineConfig({
   featureBumpBehavior: 'always'
@@ -110,7 +110,7 @@ See more about branch types in [working with branches](../how-to/working-with-br
 ::: details Example .gitversion.cjs
 
 ```js
-const { defineConfig } = require("gitbump");
+const { defineConfig } = require("gitversion");
 
 module.exports = defineConfig({
   mainBranchPatterns: [
@@ -140,7 +140,7 @@ See more about branch types in [working with branches](../how-to/working-with-br
 ::: details Example .gitversion.cjs
 
 ```js
-const { defineConfig } = require("gitbump");
+const { defineConfig } = require("gitversion");
 
 module.exports = defineConfig({
   releaseBranchPatterns: [
@@ -171,7 +171,7 @@ See more about branch types in [working with branches](../how-to/working-with-br
 ::: details Example .gitversion.cjs
 
 ```js
-const { defineConfig } = require("gitbump");
+const { defineConfig } = require("gitversion");
 
 module.exports = defineConfig({
   featureBranchPatterns: [
@@ -198,7 +198,7 @@ This will be used by all permanent actions to only run the logic without actuall
 
 ::: details Example .gitversion.cjs
 ```js
-const { defineConfig } = require("gitbump");
+const { defineConfig } = require("gitversion");
 
 module.exports = defineConfig({
   dryRun: true
@@ -219,7 +219,7 @@ Every tag in gitversion is prefixed. By default this is 'v' to get 'v1.0.0'. You
 
 ::: details Example .gitversion.cjs
 ```js
-const { defineConfig } = require("gitbump");
+const { defineConfig } = require("gitversion");
 
 module.exports = defineConfig({
   versionTagPrefix: 'version-'

docs/sidebar.mjs

@@ -1,6 +1,6 @@
 export const sidebar = [
   {
-    text: 'Gitbump', items: [
+    text: 'Gitversion', items: [
       { text: 'Introduction', link: '/' },
       { text: 'Getting started', link: '/tutorials/getting-started' },
       { text: 'Configuration', link: '/reference/configuration' },

docs/tutorials/getting-started.md

@@ -23,15 +23,15 @@ Start by adding the the gitversion package to your root workspace:
 ::: code-group
 
 ```sh [yarn]
-$ yarn add -D gitbump
+$ yarn add -D gitversion
 ```
 
 ```sh [npm]
-$ npm add -D gitbump
+$ npm add -D gitversion
 ```
 
 ```sh [pnpm]
-$ pnpm add -D gitbump
+$ pnpm add -D gitversion
 ```
 
 :::
@@ -82,7 +82,7 @@ Bump will do the following:
 - restore all versions from the current state in git
 - update all versions in manifest files according to the detected bump type
 - update CHANGELOG.md files according to commit messages
-- generate a bump manifest file in the gitbump.out folder which will be used by the [pack](#Pack) command
+- generate a bump manifest file in the gitversion.out folder which will be used by the [pack](#Pack) command
 
 ### Pack
 
@@ -101,9 +101,9 @@ $ pnpm gitversion pack
 ```
 :::
 
-The pack command will generate packages but will not publish them. The packages are generated by the detected package manager. The output of the pack action will be stored inside the gitbump.out action together with a pack manifest.
+The pack command will generate packages but will not publish them. The packages are generated by the detected package manager. The output of the pack action will be stored inside the gitversion.out action together with a pack manifest.
 
-The gitbump.out folder can now be stored now in a pipeline artifact so a different stage can publish the results.
+The gitversion.out folder can now be stored now in a pipeline artifact so a different stage can publish the results.
 
 ::: tip
 If you do not need to execute anything between [bump](#Bump) and [pack](#Pack) you can skip the bump command. Pack will execute it when there is no bump manifest.
@@ -127,7 +127,7 @@ $ pnpm gitversion publish
 ```
 :::
 
-Publish is the only command that will make permanent changes. Publish will need the workspace in order to update changelog files but will only get its information from the pack information in the gitbump.out folder.
+Publish is the only command that will make permanent changes. Publish will need the workspace in order to update changelog files but will only get its information from the pack information in the gitversion.out folder.
 
 Publish will execute the following:
 - use the package manager to publish the packages
@@ -137,7 +137,7 @@ Publish will execute the following:
 - push the changelogs
 
 ::: tip
-If you do not need to split the [pack](#Pack) and [publish](#Publish) stages you can skip pack. Publish will try to pack the workspace when there is no pack output in the gitbump.out folder.
+If you do not need to split the [pack](#Pack) and [publish](#Publish) stages you can skip pack. Publish will try to pack the workspace when there is no pack output in the gitversion.out folder.
 This means you can use publish as a single command to do bump -> pack -> publish
 :::