Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Version Control and Tagging (Packages) #2842

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down
78 changes: 78 additions & 0 deletions website/docs/packages/reference/versioning.md
Original file line number Diff line number Diff line change
@@ -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.






9 changes: 8 additions & 1 deletion website/docs/packages/tutorial/js-module.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down Expand Up @@ -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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion: to make it more clear that the difference of git vs. non-git is only in edit mode and that deploy mode has the same behavior no matter the git connection exists or not, what if we change the order of the text to something like:

:::info
When you update and publish a package, these modifications automatically apply in the edit mode of the app. If the package is git-connected, it continues to use the previous version until it is changed directly. 
However, in both cases, the live (deployed) version of the app remains unchanged until you redeploy the app. 

:::

### See also
Expand Down
14 changes: 7 additions & 7 deletions website/docs/packages/tutorial/query-module.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down Expand Up @@ -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>



Expand Down
3 changes: 2 additions & 1 deletion website/sidebars.js
Original file line number Diff line number Diff line change
Expand Up @@ -760,7 +760,8 @@ const sidebars = {
label: 'Reference',
items: [
'packages/reference/package',
'packages/reference/query-module'
'packages/reference/query-module',
'packages/reference/versioning'
],
}
]
Expand Down