feat: Version Control and Tagging (Packages) (#2842)

## Description 

Provide a concise summary of the changes made in this pull request
- 

## Pull request type

Check the appropriate box:

- [ ] Review Fixes
- [ ] Documentation Overhaul
- [ ] Feature/Story
    - Link one or more Engineering Tickets
        * 
- [ ] A-Force
- [ ] Error in documentation
- [ ] Maintenance

## Documentation tickets

 Link to one or more documentation tickets:
 - 

## Checklist

From the below options, select the ones that are applicable:

- [ ] Checked for Grammarly suggestions.
- [ ] Adhered to the writing checklist.
- [ ] Adhered to the media checklist.
- [ ] Verified and updated cross-references or added redirect rules.
- [ ] Tested the redirect rules on deploy preview.
- [ ] Validated the modifications made to the content on the deploy
preview.
- [ ] Validated the CSS modifications on different screen sizes.

Author: harshilp24

website/docs/packages/how-to-guides/pass-date-between-modules.md

@@ -117,7 +117,13 @@ export default {
 
 
 
-3. Publish the package.
+3. **Publish** the Package from top-right corner. This allows the changes to reflect on the app side. 
+
+<dd>
+
+If the package is git-connected, you also need to release a new version for the changes to be available. For more details, refer to [Package Version Control](/packages/reference/versioning).
+
+</dd>
 
 4. Open your App from the homepage and ensure that both the app and modules share the same workspace.
 

website/docs/packages/reference/versioning.md

@@ -0,0 +1,78 @@
+# Package Version Control 
+
+This page provides information about versioning and tagging in Packages. You can connect a Package to any Git remote repository, similar to applications. When a Package is Git-connected, you can commit changes, merge branches, and create tagged releases.
+
+A Package repository is separate from the application's repository. If a Package is not connected to Git, the latest version is always used, and manual versioning is not available. To connect a Package to Git, see [Version Control With Git](/advanced-concepts/version-control-with-git).
+
+
+## Managing Package Versions
+
+You can manage versions of a Git-connected Package using the Commit button in the top-right corner of the interface. This opens the Commit Modal, where you can commit changes, merge branches, and release a new Package version.
+
+If the Package is not Git-connected, the Deploy button appears instead of Commit. Deploying applies changes immediately without version control.
+
+
+
+
+#### Deploy
+
+<dd>
+
+The Deploy section allows you to commit changes to the active Git branch. You can see Changes since the last deployment, such as updates to queries and JS modules.
+
+- If there are uncommitted changes, they must be committed before merging or releasing.
+- You can provide a commit message to describe the update.
+- Clicking **Commit & Push** Changes synchronizes the latest modifications with the repository.
+- The **Discard & Pull** button discards all local changes and pulls the latest updates from the remote repository.
+
+
+</dd>
+
+#### Merge
+
+<dd>
+
+The Merge section allows you to combine updates from a source branch into a target branch.
+Before merging, ensure that both branches have the latest committed changes and that there are no merge conflicts.
+
+- Merging incorporates updates from feature or development branches before releasing.
+- If conflicts exist, Git prompts you to resolve them before completing the merge.
+- After merging, the target branch reflects the latest updates.
+
+For more details, see [How to Resolve Merge Conflicts](/advanced-concepts/version-control-with-git/commit-and-push).
+
+
+
+</dd>
+
+#### Release
+
+<dd>
+
+The Release tab allows you to tag a version based on the latest commit in the repository. This feature is built on [Git tagging](https://git-scm.com/book/en/v2/Git-Basics-Tagging) and currently applies only to Packages. The latest commit is tagged with the selected version, and uncommitted changes are not included in the release.
+
+Version tagging allows applications to reference a specific release instead of the latest changes. It follows semantic versioning, where each increment indicates the type of update.
+
+- **Major (1.x.x → 2.0.0)**: Indicates breaking changes that require modifications in dependent applications. For example: Removing or renaming existing functions.
+
+- **Minor (1.0.x → 1.1.0)**: Introduces new features while maintaining backward compatibility. For example: Adding a new method without modifying existing functionality.
+
+- **Patch (1.0.0 → 1.0.1)**: Applies bug fixes or minor improvements that do not affect functionality. For example: Resolving an error in an existing function.
+
+
+</dd>
+
+
+## Using Package Versions in Applications
+
+You can select a Package version from the **Libraries** section in the **Entity Explorer** by choosing from the available options. Only Packages currently used in the application are listed. If a Package or module is not used in the application, it will not appear in the selection menu.
+
+- **For Git-connected Packages:** You can choose from a list of available Package versions that have been released. Each version corresponds to a tagged commit, allowing you to control which version is used in your application. 
+
+- **For Non-Git-connected Packages:** Version selection is not available, and the application always uses the latest Package version. Any updates to the Package are immediately applied without version control.
+
+
+
+
+
+

website/docs/packages/tutorial/js-module.md

@@ -92,8 +92,13 @@ export default {
 </dd>
 
 
+5. **Publish** the JS module from top-right corner. This allows the changes to reflect on the app side. 
 
-5. **Publish** the JS Module.
+<dd>
+
+If the package is git-connected, you also need to release a new version for the changes to be available. For more details, refer to [Package Version Control](/packages/reference/versioning).
+
+</dd>
 
 ## Use JS module
 
@@ -145,6 +150,8 @@ With this, you can format dates using the JS module in multiple places throughou
 
 :::info
 When you update and publish a package, these modifications automatically apply in the edit mode of the app. However, the live (deployed) version of the app remains unchanged until you redeploy the app. 
+
+If the package is git-connected, it continues to use the previous version until it is changed directly while editing the app.
 :::
 
 ### See also

website/docs/packages/tutorial/query-module.md

@@ -28,12 +28,6 @@ You'll create a reusable query module using product inventory data and display t
 * ♻️ **Reusability:** Discover how to reuse the query module within applications
 :::
 
-## Prerequisites
-Before you start, make sure you have the following:
-
-* A self-hosted instance of Appsmith with a [paid subscription](https://www.appsmith.com/pricing). Refer to the [Appsmith installation guides](/getting-started/setup/installation-guides) for detailed instructions on setting up your Appsmith instance.
-* If you are new to Appsmith, see [Tutorial - Basics](/getting-started/tutorials/start-building).
-
 
 ## Create query module
 
@@ -126,7 +120,13 @@ SELECT * FROM public."product" LIMIT {{inputs.limit}} OFFSET {{inputs.offset}};
 11. **Run** the query to ensure it retrieves the data correctly.
 
 
-12. **Publish** the query module from top-right corner. This allows the changes to reflect on the app side.
+12. **Publish** the query module from top-right corner. This allows the changes to reflect on the app side. 
+
+<dd>
+
+If the package is git-connected, you also need to release a new version for the changes to be available. For more details, refer to [Package Version Control](/packages/reference/versioning).
+
+</dd>
 
 
 

website/sidebars.js

@@ -764,7 +764,8 @@ const sidebars = {
             label: 'Reference',
             items: [
               'packages/reference/package',
-              'packages/reference/query-module'
+              'packages/reference/query-module',
+              'packages/reference/versioning'
             ],
           }
         ]