🔀 switch from development to master as default branch

To simplify the application lifecycle management and to provide a cleaner commit history, the default branch was switched form development to master. The development branch will eventually be deleted and there will be only master as the single permanent branch of the repository.

.github/workflows/build.yml

@@ -5,7 +5,7 @@ name: d365fo.tools-PR-Test
 on:
   push:
     branches:
-      - development
+      - master
   pull_request:
   workflow_dispatch:
 

.github/workflows/update-wiki.yml

@@ -7,7 +7,7 @@ on:
       - 'wiki/**'
       - 'docs/**'
     branches:
-      - development
+      - master
 
   # Allows you to run this workflow manually from the Actions tab
   workflow_dispatch:

contributing.md

@@ -18,15 +18,15 @@ If you wanna help out to make the module even more robust
 Documentation is really the area we welcome any help possible. The documentation refers to CBH (Comment Based Help). The CBH documentation is included with each command and is the content you see when you run `Get-Help Function-Name`. If any of that content is not clear enough or if the examples in the functions are not working, you should say so (e.g. raise an issue on GitHub or contact us on twitter). Even if you are a casual user or a PowerShell newbie, we need your angle to make it as straight forward and clear as possible.
 
 ## Contribute New Commands
-Start out reviewing the [list of functions on in the docs folder](https://github.com/d365collaborative/d365fo.tools/tree/development/docs), or pulling the list from the module with `Get-Command -Module d365fo.tools -CommandType Function | Out-GridView`. If you find something similar already exists, open [a new issue on GitHub](https://github.com/d365collaborative/d365fo.tools/issues/new) to request an enhancement to that command. If nothing similar pops up, either ping @splaxi on twitter with your idea about the new command or open a new issue on GitHub with details or requirements you need.
+Start out reviewing the [list of functions on in the docs folder](https://github.com/d365collaborative/d365fo.tools/tree/master/docs), or pulling the list from the module with `Get-Command -Module d365fo.tools -CommandType Function | Out-GridView`. If you find something similar already exists, open [a new issue on GitHub](https://github.com/d365collaborative/d365fo.tools/issues/new) to request an enhancement to that command. If nothing similar pops up, either ping @splaxi on twitter with your idea about the new command or open a new issue on GitHub with details or requirements you need.
 
 ## Report Bugs
 [Open a new issue](https://github.com/d365collaborative/d365fo.tools/issues/new) on GitHub and fill in all the details. The title should report the affected function, followed by a brief description (e.g. _Get-D365Environment - Add property x to default view_). The provided template holds most of the details coders need to fix the issue.
 
 ## Fix Bugs
 If you feel for fixing a bug, but don't know GitHub enough, the dbatools.io project has a good starting guide. We are on the same team, so instead of us writing a guide that is close to theirs - we simply point to theirs [step-by-step guide](https://dbatools.io/firstpull).
 
-[Open a PR](https://github.com/d365collaborative/d365fo.tools/pulls) targeting ideally just one ps1 file (the PR needs to target the *development* branch), with the name of the function being fixed as a title. Everyone will chime in reviewing the code and either approve the PR or request changes. The more targeted and focused the PR, the easier to merge, the fastest to go into the next release. Keep them as simple as possible to speed up the process.
+[Open a PR](https://github.com/d365collaborative/d365fo.tools/pulls) targeting ideally just one ps1 file (the PR needs to target the *master* branch), with the name of the function being fixed as a title. Everyone will chime in reviewing the code and either approve the PR or request changes. The more targeted and focused the PR, the easier to merge, the fastest to go into the next release. Keep them as simple as possible to speed up the process.
 
 ## Branching
 Make sure to read our [branching guide](https://github.com/d365collaborative/d365fo.tools/wiki/Branching) on the wiki to get a good starting point.

wiki/Branching.md

@@ -7,11 +7,11 @@ One of the benefits of having a feature branch is that if you want to submit mul
 ## **Create a new branch from the desktop client**
 
 1. Make sure that you have selected your local repository
-2. Make sure that you have selected the development branch
+2. Make sure that you have selected the master branch
 
 [[images/Branch.001.png]]
 
-3. Click on the **development** branch icon in the top
+3. Click on the **master** branch icon in the top
 4. Click on the **New branch** button in the drop down menu
 
 [[images/Branch.002.png]]
@@ -36,6 +36,6 @@ One of the benefits of having a feature branch is that if you want to submit mul
 [[images/Branch.006.png]]
 
 11. Your default browser will now load and go to github
-12. Make sure that you compared the branch against the **development** branch in the d365fo.tools repository
+12. Make sure that you compared the branch against the **master** branch in the d365fo.tools repository
 
 [[images/Branch.007.png]]

wiki/Building-tools.md

@@ -1,8 +1,8 @@
 When you contribute to the d365fo.tools project you will quickly learn that we have several validation steps that might throw an error when you are creating PR's against the repository.
 
-These validations are checked when you create a pull request. The checks are done by GitHub Actions and are defined in the [build.yml](https://github.com/d365collaborative/d365fo.tools/blob/development/.github/workflows/build.yml) file. The GitHub Action will run the PowerShell scripts in the [build](https://github.com/d365collaborative/d365fo.tools/tree/development/build) folder of the repository starting with `vsts-`.
+These validations are checked when you create a pull request. The checks are done by GitHub Actions and are defined in the [build.yml](https://github.com/d365collaborative/d365fo.tools/blob/master/.github/workflows/build.yml) file. The GitHub Action will run the PowerShell scripts in the [build](https://github.com/d365collaborative/d365fo.tools/tree/master/build) folder of the repository starting with `vsts-`.
 
-For some of the checks, we have created PowerShell scripts that can be used to automatically make the changes needed to pass the validation. You can run these scripts locally on your machine to make the changes needed before you create a pull request. They are also available as a GitHub Action defined in the [update-generated-text.yml](https://github.com/d365collaborative/d365fo.tools/blob/development/.github/workflows/update-generated-text.yml). If you have your own fork of the repository, you can use this action to automatically update the generated files in your pull requests.
+For some of the checks, we have created PowerShell scripts that can be used to automatically make the changes needed to pass the validation. You can run these scripts locally on your machine to make the changes needed before you create a pull request. They are also available as a GitHub Action defined in the [update-generated-text.yml](https://github.com/d365collaborative/d365fo.tools/blob/master/.github/workflows/update-generated-text.yml). If you have your own fork of the repository, you can use this action to automatically update the generated files in your pull requests.
 
 To run the scripts locally, follow the instructions below.
 
@@ -13,16 +13,16 @@ To run the scripts locally, follow the instructions below.
    * `Install-Module platyPS -Force -Confirm:$false`
 
 ## **Format Comment Based help**
-We try to keep the formatting of the Comment Based Help the same across every contributor. This is done by the [Format-CommentBasedHelp.ps1](https://github.com/d365collaborative/d365fo.tools/tree/development/build/format-commentbasedhelp.ps1) script. If you want to find out more about comment based help, take a look at [about Comment Based Help](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_comment_based_help).
+We try to keep the formatting of the Comment Based Help the same across every contributor. This is done by the [Format-CommentBasedHelp.ps1](https://github.com/d365collaborative/d365fo.tools/tree/master/build/format-commentbasedhelp.ps1) script. If you want to find out more about comment based help, take a look at [about Comment Based Help](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_comment_based_help).
 
 ## **Generate-ParameterUnitTests**
-We try to mitigate the drifting changes that might get introduced when multiple people contribute to the same project. We also try to ensure that the parameters do not change **without** us knowing about it. This helps us update the examples inside the Comment Based Help and therefor the user base. This is done by the [Generate-ParameterUnitTests.ps1](https://github.com/d365collaborative/d365fo.tools/tree/development/build/generate-parameterunittests.ps1) script. This script will generate a new test file for each command in the module, using the `Invoke-PSMDTemplate` cmdlet of [PSModuleDevelopment](https://github.com/PowershellFrameworkCollective/PSModuleDevelopment). The tests will check a list of best practices.
+We try to mitigate the drifting changes that might get introduced when multiple people contribute to the same project. We also try to ensure that the parameters do not change **without** us knowing about it. This helps us update the examples inside the Comment Based Help and therefor the user base. This is done by the [Generate-ParameterUnitTests.ps1](https://github.com/d365collaborative/d365fo.tools/tree/master/build/generate-parameterunittests.ps1) script. This script will generate a new test file for each command in the module, using the `Invoke-PSMDTemplate` cmdlet of [PSModuleDevelopment](https://github.com/PowershellFrameworkCollective/PSModuleDevelopment). The tests will check a list of best practices.
 
 ## **Update-Docs**
-Whenever we release a new version of the module, we push the updated markdown files used for documentation, to make sure that users can lookup parameter names and parameterset specification. This is done by the [Update-Docs.ps1](https://github.com/d365collaborative/d365fo.tools/tree/development/build/update-docs.ps1) script. The markdown files are created from the Comment Based Help in the module. The `New-MarkdownHelp` cmdlet of [platyPS](https://learn.microsoft.com/en-us/powershell/utility-modules/platyps/overview) is used to create the markdown files.
+Whenever we release a new version of the module, we push the updated markdown files used for documentation, to make sure that users can lookup parameter names and parameterset specification. This is done by the [Update-Docs.ps1](https://github.com/d365collaborative/d365fo.tools/tree/master/build/update-docs.ps1) script. The markdown files are created from the Comment Based Help in the module. The `New-MarkdownHelp` cmdlet of [platyPS](https://learn.microsoft.com/en-us/powershell/utility-modules/platyps/overview) is used to create the markdown files.
 
 ## **Generate-FindCommandIndex**
-The [Find-D365Command](Find-D365Command.md) is used to find commands in the module. It acts faster than the built-in Get-Help cmdlet, but it requires a file to be updated whenever a new command is added to the module. This script will update the file with the new command. Find the script in the build folder of the repository: [Generate-FindCommandIndex.ps1](https://github.com/d365collaborative/d365fo.tools/tree/development/build/Generate-FindCommandIndex.ps1).
+The [Find-D365Command](Find-D365Command.md) is used to find commands in the module. It acts faster than the built-in Get-Help cmdlet, but it requires a file to be updated whenever a new command is added to the module. This script will update the file with the new command. Find the script in the build folder of the repository: [Generate-FindCommandIndex.ps1](https://github.com/d365collaborative/d365fo.tools/tree/master/build/Generate-FindCommandIndex.ps1).
 
 ## **Closing notes**
 The reason why we keep these steps manual for the time being is to make sure that nothing gets updated without we either knowing about it or without us making a "decision" to update these things.

wiki/Configuration.md

@@ -2,7 +2,7 @@ Many d365fo.tools cmdlets use default values for their parameters. This makes th
 
 # An example
 
-For example, the [Get-D365Module](https://github.com/d365collaborative/d365fo.tools/blob/development/d365fo.tools/functions/get-d365module.ps1) cmdlet has a `-PackageDirectory` parameter. The documentation for the parameter says *Normally it is located under AOSService directory in "PackagesLocalDirectory" - Default value is fetched from the current configuration on the machine*. Looking at the code of the cmdlet, it specifies the parameter like this: `[string] $PackageDirectory = $Script:PackageDirectory`.
+For example, the [Get-D365Module](https://github.com/d365collaborative/d365fo.tools/blob/master/d365fo.tools/functions/get-d365module.ps1) cmdlet has a `-PackageDirectory` parameter. The documentation for the parameter says *Normally it is located under AOSService directory in "PackagesLocalDirectory" - Default value is fetched from the current configuration on the machine*. Looking at the code of the cmdlet, it specifies the parameter like this: `[string] $PackageDirectory = $Script:PackageDirectory`.
 
 We will come back to this example in the following sections to explain how the default value is determined.
 
@@ -14,7 +14,7 @@ For the purpose of the d365fo.tools module, the script scope lets us define vari
 
 # Setting the default values
 
-The values of the variables in the script scope are set in several internal scripts that get executed when the module is imported. You can see this in the [postimport.ps1](https://github.com/d365collaborative/d365fo.tools/blob/development/d365fo.tools/internal/scripts/postimport.ps1) script, where the [variables.ps1](https://github.com/d365collaborative/d365fo.tools/blob/development/d365fo.tools/internal/scripts/variables.ps1) script is called. This script sets the default values for many variables in the module. 
+The values of the variables in the script scope are set in several internal scripts that get executed when the module is imported. You can see this in the [postimport.ps1](https://github.com/d365collaborative/d365fo.tools/blob/master/d365fo.tools/internal/scripts/postimport.ps1) script, where the [variables.ps1](https://github.com/d365collaborative/d365fo.tools/blob/master/d365fo.tools/internal/scripts/variables.ps1) script is called. This script sets the default values for many variables in the module. 
 
 ## It depends
 
@@ -37,7 +37,7 @@ The common theme for these variables is that they are based on configuration val
 
 Another important thing to note is that the configuration values are persisted between sessions. This means that the user only has to set the configuration values once, and they will be used as default values for the variables in all future sessions of the module.
 
-This also applies to the `Update-ModuleVariables` function, but the configuration values are not set by the user, but by the module itself. The configuration values are specified in the [configuration.ps1](https://github.com/d365collaborative/d365fo.tools/blob/development/d365fo.tools/internal/configurations/configuration.ps1) script. To understand how those configurations work, we first need to learn about the PSFramework module.
+This also applies to the `Update-ModuleVariables` function, but the configuration values are not set by the user, but by the module itself. The configuration values are specified in the [configuration.ps1](https://github.com/d365collaborative/d365fo.tools/blob/master/d365fo.tools/internal/configurations/configuration.ps1) script. To understand how those configurations work, we first need to learn about the PSFramework module.
 
 ## PSFramework