Merge branch 'main' into 3.4.1-release-notes

docs/SQL/gems/Transformations/aggregate.md

@@ -63,7 +63,7 @@ Now let's see how to configure the `payment_methods` variable.
 ![4](../img/Snow4.6.4_Aggregate.png)
 
 1. Click **Config** to open the configuration screen.
-2. We see the option to apply a configuration at several different **levels:** apply to the entire Model, all the Models in the Github folder, or all the Models in the Project. Here we can see there are Configurations that apply to this particular `Orders` Model.
+2. We see the option to apply a configuration at several different **levels:** apply to the entire Model, all the Models in the GitHub folder, or all the Models in the Project. Here we can see there are Configurations that apply to this particular `Orders` Model.
 3. See the list of [DBT Defined Configs](https://docs.getdbt.com/reference/configs-and-properties). These are configs every user could employ with their DBT Projects, such as whether to materialize the model as table, view, ephemeral, or incremental. Click the dropdown to select the config of interest, then enter the appropriate value. Hover over the "i" icon for a short description of each DBT Config.
 4. See the list of user-defined **Variables**. In our HelloWorld_SQL project, the `payment_methods` variable has been defined with the four **values** shown.
 5. Click **Save** after editing the Config for the Model, Folder, or Project.

docs/Spark/pipeline-monitoring/enable-pipeline-monitoring.md

@@ -27,7 +27,7 @@ You can check your **ProphecyLibsPython** version under **Dependencies**.
 
 If you have uncommitted changes in your Pipelines, you may be prompted to either **Commit & Save** or **Save Without Committing**. The update will affect all Pipelines in your Project.
 
-For an up-to-date list of Prophecy versions and libraries, see [Version Chart](/docs/release_notes/version_chart.md).
+For an up-to-date list of Prophecy versions and libraries, see [Version Chart](/docs/release_notes/version_chart/version_chart.md).
 
 ## Turn on the Pipeline Monitoring flag
 

docs/concepts/concepts.md

@@ -19,7 +19,7 @@ A **project** contains
 
 ### Project is Code on Git
 
-A **project** is **code** on **Git**. This means that within a project, the business logic of all the assets including _Pipelines_/_Models_, _Datasets_, and _Jobs_ is stored as code on Git. This might be a repository on Github or a folder in a repository.
+A **project** is **code** on **Git**. This means that within a project, the business logic of all the assets including _Pipelines_/_Models_, _Datasets_, and _Jobs_ is stored as code on Git. This might be a repository on GitHub or a folder in a repository.
 
 ![Project is code](img/project_is_code.png)
 

docs/concepts/copilot/copilot.md

@@ -45,15 +45,15 @@ For more details, see [Enable Data Copilot](/concepts/copilot/enable-data-copilo
 
 ###
 
-#### How is Prophecy Copilot different than Github Copilot?
+#### How is Prophecy Copilot different than GitHub Copilot?
 
-Github Copilot is a great tool to boost productivity and extend the reach of the coding community. However, not every problem is solved with direct coding. More importantly, users need a Copilot with some context of the interesting data.
+GitHub Copilot is a great tool to boost productivity and extend the reach of the coding community. However, not every problem is solved with direct coding. More importantly, users need a Copilot with some context of the interesting data.
 
 For teams of analysts, data platform providers, or line-of-business users, the pain points are not resolved by teaching every team member how to code. Data Copilot empowers less technical users because they don’t have to code. Importantly, technical and coding users benefit from Data Copilot because visual Pipelines are easier to understand, explain, and leverage. Prophecy’s Data Copilot boosts the productivity of the business user and the more technical coding team members.
 
 When all of these data practitioners reach for an AI assistant, they’ll need one specific to the data space. For example, the assistant should collect metadata from the data warehouse, catalog, or storage provider. Prophecy Data Copilot has the context of your data, and it can guide Pipeline and Model development by suggesting which Datasets to use and how to use them.
 
-Github Copilot and Prophecy Data Copilot are both excellent tools to boost productivity, but Prophecy Data Copilot is accessible to a larger user base and can make data suggestions because it maintains data context.
+GitHub Copilot and Prophecy Data Copilot are both excellent tools to boost productivity, but Prophecy Data Copilot is accessible to a larger user base and can make data suggestions because it maintains data context.
 
 #### Which Datasets are accessible to Prophecy Data Copilot?
 

docs/concepts/fabrics/prophecy-libs.md

@@ -17,7 +17,7 @@ You can see which Prophecy Libs version is running on your Spark cluster by chec
 
 <img src={require('./img/libs-version-cluster.png').default} alt="Prophecy libs version in the Fabric cluster" width="58%" />
 
-For a list of the latest versions, see [Version Chart](/docs/release_notes/version_chart.md).
+For a list of the latest versions, see [Version Chart](/docs/release_notes/version_chart/version_chart.md).
 
 ## Functionality
 

docs/concepts/project/project.md

@@ -18,7 +18,7 @@ A **project** contains
 
 ## Projects are Code on Git
 
-A **project** is **code** on **Git**. This means that within a project, the business logic of all the assets including _Pipelines_/_Models_, _Datasets_, and _Jobs_ is stored as code on Git. This might be a repository on Github or a folder in a repository.
+A **project** is **code** on **Git**. This means that within a project, the business logic of all the assets including _Pipelines_/_Models_, _Datasets_, and _Jobs_ is stored as code on Git. This might be a repository on GitHub or a folder in a repository.
 
 ![Project is code](../img/project_is_code.png)
 

docs/deployment/prophecy-build-tool/pbt-github-actions.md

@@ -1,7 +1,7 @@
 ---
-title: PBT on Github Actions
+title: PBT on GitHub Actions
 id: prophecy-build-tool-github-actions
-description: Example usage of Prophecy Build Tool on Github Actions
+description: Example usage of Prophecy Build Tool on GitHub Actions
 sidebar_position: 5
 tags:
   - metadata
@@ -15,31 +15,31 @@ tags:
   - cicd
 ---
 
-## [Example Github Repo](https://github.com/prophecy-samples/external-cicd-template)
+## [Example GitHub Repo](https://github.com/prophecy-samples/external-cicd-template)
 
 ## Integrating with GitHub Actions
 
-PBT can be integrated with your own CI/CD solution to build, test and deploy Prophecy code. The steps for setting up PBT with Github Actions on your repository containing a Prophecy project are mentioned below.
+PBT can be integrated with your own CI/CD solution to build, test and deploy Prophecy code. The steps for setting up PBT with GitHub Actions on your repository containing a Prophecy project are mentioned below.
 
 ### Pre-requisite
 
-- A Prophecy project that is currently hosted in a Github repository
+- A Prophecy project that is currently hosted in a GitHub repository
 
 ### Setting up environment variables and secrets
 
 PBT requires environment variables **DATABRICKS_URL** and **DATABRICKS_TOKEN** to be set for complete functionality.
 
-The **DATABRICKS_TOKEN** that needs to be used can be set as a secret inside the Github repository of the project.
+The **DATABRICKS_TOKEN** that needs to be used can be set as a secret inside the GitHub repository of the project.
 Steps:
 
-- Go to Settings > Secrets > Actions from the Github repository menu
+- Go to Settings > Secrets > Actions from the GitHub repository menu
 - Click ‘New Repository secret’
 - Add the secret with name DATABRICKS_TOKEN and value of the Databricks token to be used by PBT.
 
 Screenshot after setting DATABRICKS_TOKEN secret:
-![Github Actions Secret addition](img/pbt-github-secret.png)
+![GitHub Actions Secret addition](img/pbt-github-secret.png)
 
-The environment variables can now be all set within the Github actions YML file as follows:
+The environment variables can now be all set within the GitHub actions YML file as follows:
 
 ```yaml
 env:
@@ -63,7 +63,7 @@ To setup a workflow to build, run all unit tests and then deploy the built jar (
 - Add the below contents to **exampleWorkflow.yml**
 
   ```yaml
-  name: Example CI/CD with Github actions
+  name: Example CI/CD with GitHub actions
   on:
   push:
   branches: - "prod"

docs/deployment/prophecy-build-tool/pbt-jenkins.md

@@ -15,15 +15,15 @@ tags:
   - jenkins
 ---
 
-## [Example Github Repo](https://github.com/prophecy-samples/external-cicd-template)
+## [Example GitHub Repo](https://github.com/prophecy-samples/external-cicd-template)
 
 ## Context of the Jenkins CI/CD Example
 
 In this section we will explore how to set up separate "testing" and "deploying" Jenkins Jobs using declarative Pipelines. These Jobs will be triggered when items are merged into the following protected branches
 `prod`, `qa`, `develop`. Each of these three branches represents a different Databricks Workspace environment. We
 want to be able to test and deploy our Pipelines into each of these three workspaces during our release workflow.
 
-The release process on Github is defined as merging and testing to branches in the following
+The release process on GitHub is defined as merging and testing to branches in the following
 order: `feature-branch` > `develop` > `qa` > `prod`
 
 ![branch_protection_checks_example.png](img%2Fbranch_protection_checks_example.png)
@@ -54,9 +54,9 @@ You should have access to:
 
 The following plugins were used for this example:
 
-- [Github Pull Request Builder](https://plugins.jenkins.io/ghprb/)
+- [GitHub Pull Request Builder](https://plugins.jenkins.io/ghprb/)
   - for the build/test Job
-- [Github](https://plugins.jenkins.io/github/)
+- [GitHub](https://plugins.jenkins.io/github/)
   - for the deploy Job
 
 :::caution
@@ -101,10 +101,10 @@ This Pipeline uses PBT to validate the pipelines and run all Prophecy unit tests
 
 - Create a Jenkins Pipeline
   ![jenkins-pipeline-type.png](img%2Fjenkins-pipeline-type.png)
-- Configure the Github Project URL
-- Choose Github Pull Request Builder as the trigger type.
-- Provide credentials to Github
-  - creating a fine-grained Personal Acces Token (PAT) in Github. The PAT should be
+- Configure the GitHub Project URL
+- Choose GitHub Pull Request Builder as the trigger type.
+- Provide credentials to GitHub
+  - creating a fine-grained Personal Acces Token (PAT) in GitHub. The PAT should be
     scoped to yourself or your Organization, have access to the repository containing the Prophecy project, and
     appropriate permissions:
     ![github-pat-permissions.png](img%2Fgithub-pat-permissions.png)
@@ -120,11 +120,11 @@ This Pipeline uses PBT to validate the pipelines and run all Prophecy unit tests
 
 ### Testing Pipeline - Trigger
 
-We use the [Github Pull Request Builder](https://plugins.jenkins.io/ghprb/) to trigger any time there is a new pull request or a change
+We use the [GitHub Pull Request Builder](https://plugins.jenkins.io/ghprb/) to trigger any time there is a new pull request or a change
 on a pull request (comment or new commit) to our special branches: `develop`, `qa`, `prod`.
 
-By providing Github credentials to the GHPRB plugin it will be able to automatically
-create webhooks in Github.
+By providing GitHub credentials to the GHPRB plugin it will be able to automatically
+create webhooks in GitHub.
 
 <details>
 <summary> Refer to this image for all settings. </summary>
@@ -217,8 +217,8 @@ This Pipeline uses PBT to deploy the Prophecy Pipelines to their appropriate Fab
 
 - Create a Jenkins Pipeline
   ![jenkins-pipeline-type.png](img%2Fjenkins-pipeline-type.png)
-- Choose "Github hook for GITScm polling" as the trigger.
-- Choose "Pipeline from SCM" with our Github repo as the repository
+- Choose "GitHub hook for GITScm polling" as the trigger.
+- Choose "Pipeline from SCM" with our GitHub repo as the repository
 - Choose the branches to trigger on (`develop`, `qa`, `prod`)
 - Point the "Script path" [to our Jenkinsfile](#deploy-pipeline---pipeline-code) containing the deploy logic
 
@@ -231,7 +231,7 @@ This Pipeline uses PBT to deploy the Prophecy Pipelines to their appropriate Fab
 
 ### Deploy Pipeline - Trigger
 
-Set up a simple webhook trigger for this Job inside of Github.
+Set up a simple webhook trigger for this Job inside of GitHub.
 
 - Navigate to `Settings > Webhooks > Add Webhook`
 - Create a new webhook like this:

docs/deployment/prophecy-build-tool/prophecy-build-tool.md

@@ -14,7 +14,7 @@ tags:
 ---
 
 **Prophecy-built-tool** (PBT) allows you to quickly build, test and deploy projects generated by Prophecy (your standard Spark Scala and
-PySpark Pipelines) to integrate with your own CI / CD (e.g. Github Actions), build system (e.g. Jenkins), and
+PySpark Pipelines) to integrate with your own CI / CD (e.g. GitHub Actions), build system (e.g. Jenkins), and
 orchestration (e.g. Databricks Workflows).
 
 ## Features (v1.1.0)
@@ -43,7 +43,7 @@ pip3 install prophecy-build-tool
 
 ## Integration Examples
 
-### [Github Actions](pbt-github-actions.md)
+### [GitHub Actions](pbt-github-actions.md)
 
 ### [Jenkins](pbt-jenkins.md)
 

docs/deployment/use-external-release-tags.md

@@ -14,7 +14,7 @@ tags:
   - cicd
 ---
 
-If you use external CI-CD tools like Github or Jenkins to merge and release your projects, you can use release tags from those tools in Prophecy for deployment and dependencies. Once you've deployed the tags via Prophecy, you can add them as a dependency to your Projects.
+If you use external CI-CD tools like GitHub or Jenkins to merge and release your projects, you can use release tags from those tools in Prophecy for deployment and dependencies. Once you've deployed the tags via Prophecy, you can add them as a dependency to your Projects.
 
 Any externally created release tag that you pull into Prophecy is visible on Releases and Deployments.
 

docs/getting-started/getting-started-sql-snowflake.md

@@ -21,7 +21,7 @@ This quick-start gets you up and running with **building data transformations us
 #### You will need
 
 - Snowflake Account
-- Github Account (recommended)
+- GitHub Account (recommended)
 
 ## 1. Setup Prophecy account
 
@@ -111,7 +111,7 @@ Once the basic project information is filled out, it’s time to configure the G
 
 ![Git Repository Connection](img/Snow3.2_connectToGit.png)
 
-You'll see two options to connect to Git. **(1) Prophecy Managed Git Credentials** are not supported for this use case. You will need a Github account for this getting started guide. If you don't have one, create one by following [these instructions](https://docs.github.com/en/get-started/start-your-journey/creating-an-account-on-github). Select **(2) Connect to External Git** to connect to your external Git account.
+You'll see two options to connect to Git. **(1) Prophecy Managed Git Credentials** are not supported for this use case. You will need a GitHub account for this getting started guide. If you don't have one, create one by following [these instructions](https://docs.github.com/en/get-started/start-your-journey/creating-an-account-on-github). Select **(2) Connect to External Git** to connect to your external Git account.
 
 ### 3.1 Connect to external Git repository
 
@@ -121,13 +121,13 @@ When connecting to external Git repositories, you have to first setup a Git conn
 
 #### 3.1.1 Connecting with GitHub
 
-![Connect With Github](img/Snow3.3_LinkAndAuthorize.png)
+![Connect With GitHub](img/Snow3.3_LinkAndAuthorize.png)
 
-If you have an existing GitHub account this process is very simple, thanks to Prophecy’s strong OAuth GitHub integration. If you don’t have an account, you can create one at [Github.com](http://github.com).
+If you have an existing GitHub account this process is very simple, thanks to Prophecy’s strong OAuth GitHub integration. If you don’t have an account, you can create one at [GitHub.com](http://github.com).
 
 1. **Alias** - Each Git connection in Prophecy starts with an **Alias** that’s going to be used to allow you to identify the right Git account. In most cases, this can be left as default.
 
-2. **Login with Github** - redirects you to a GitHub login page (if you're not yet logged in).
+2. **Login with GitHub** - redirects you to a GitHub login page (if you're not yet logged in).
 
 3. **Sign in** - or create a new GitHub account.
 

docs/getting-started/getting-started-with-low-code-sql.md

@@ -132,9 +132,9 @@ To see a dropdown of repositories accessible to the Git user, be sure to connect
 
 #### 3.2.1 Connecting with GitHub
 
-![Connect With Github](img/3-4-connect-with-github.png)
+![Connect With GitHub](img/3-4-connect-with-github.png)
 
-If you have an existing GitHub account this process is very simple, thanks to Prophecy’s strong OAuth GitHub integration. If you don’t, you can create an account at [Github.com](http://github.com).
+If you have an existing GitHub account this process is very simple, thanks to Prophecy’s strong OAuth GitHub integration. If you don’t, you can create an account at [GitHub.com](http://github.com).
 
 Each Git connection in Prophecy starts with an **(1) Alias** that’s going to be used to allow you to identify the right Git account. In most cases, this can be left as default. With that set click **(2) Login** with GitHub which will redirect you to a GitHub login page (if you’re not yet logged in). Enter your details and **(3) Sign in** or create a new account. From there, you’ll be asked to approve Prophecy as a valid application.
 

docs/metadata/pull-request-templates.md

@@ -28,7 +28,7 @@ The `{{source}}` variable represents the active development branch, and the
 represents the base branch to which the feature/development branches need to be merged to
 , eg. `main`.
 
-Example template for a Github repository:
+Example template for a GitHub repository:
 
 ```shell
 https://github.com/exampleOrg/exampleRepo/compare/{{destination}}...{{source}}?expand=1
@@ -44,7 +44,7 @@ https://github.com/exampleOrg/exampleRepo/compare/main...feature?expand=1
 :::info
 The pull request template would be automatically generated and populated in the `Advanced` > `Pull Request Template`
 settings depending on your configured external Git provider. This auto-generation is
-currently being done for Github, Github Enterprise, Gitlab, Gitlab Enterprise, BitBucket and Azure Devops repositories.
+currently being done for GitHub, GitHub Enterprise, Gitlab, Gitlab Enterprise, BitBucket and Azure Devops repositories.
 Users will be able to edit the autogenerated templates as well.
 :::
 An example of an autogenerated PR template for a project linked with GitHub:

docs/release_notes/version_chart/_category_.json

@@ -0,0 +1,6 @@
+{
+  "label": "Version Chart",
+  "position": 3,
+  "collapsible": true,
+  "collapsed": true
+}

docs/release_notes/version_chart.md → docs/release_notes/version_chart/version_chart.md

@@ -15,13 +15,14 @@ Check to make sure the Spark version and Scala version of your Prophecy Scala Li
 of your cluster!
 :::
 
-:::info
-Query this table using the following API and your ([personal access token](..%2Fmetadata%2FprophecyAPI.md)):
+You can query this table using the following API and your [personal access token](/docs/metadata/prophecyAPI.md):
 
 ```bash
 curl  --header 'X-Auth-Token: $PROPHECY_PAT' --location https://app.prophecy.io/api/editor/plibVersions
 ```
 
+:::note
+Prophecy versions that are labeled with `EM` are Extended Maintenance releases. For more information, see [Prophecy versions support](/docs/release_notes/version_chart/versions_support.md).
 :::
 
 | Prophecy version | [Prophecy Scala libs](https://mvnrepository.com/artifact/io.prophecy/prophecy-libs) | [Prophecy Python libs](https://pypi.org/project/prophecy-libs/) | Release Date | End-of-support Date |