Below are several examples for project versioning use cases, accompanied by diagrams that illustrate them, as an end-to-end workflows.
This example shows a few cases of a developer workflow.
Create a tag, where all changes are committed and pushed and aligned with GIT.
Create a tag, where there are local changes that are not pushed to GIT. Studio, then, alerts about their presence.
However, the developer can also choose to ignore the alert and to continue with the version tagging. This is a slightly risky, yet a valid case, as the version that is about to be released should not include the features he is currently working on. In our example (depicted in the below diagram), the developer pushes his changes and re-activates the version tagging, this time without getting any alerts.
Deploy to remote server where no changes were done after creating the tag. In this case, the deployed artifacts are fully aligned with the tag, in a way that when running the version
command in the remote server, you can be assured that the version is aligned with tag artifacts.
Deploy to remote server where changes were done locally after creating the tag. In case where Warn-on-Tag-Diff is chosen in User Preferences for this remote server, Studio alerts the user. If the user chooses to proceed anyway, then the built artifacts are marked with a star (*). This way, when running the version
command in the target remote server, the user is hinted that the deployed artifacts are not fully aligned with the tagged version.
version
command on the server, you can be assured that it is aligned with tag artifacts in GIT.This example illustrates the case of several developers who work on the same project. This example starts when version 1.0.4 is created and two developers start working based on it (it is assumed that the branch is fully aligned with the tag. You can see in example 1 that it is not necessarily the case).
This is a legitimate case, where another developer continues with an implementation that is aimed for a later version. Accordingly, DEV 1 should verify, before proceeding, that DEV 2's changes shall not be part of the current version's content.
This example illustrates a required-hotfix case, where one of the developers handles the hotfix implementation, while another continues to work on the main branch, without any collisions.
When he starts developing, the GIT would detach the developer from the tag, where he would need to push his changes to a new branch.
Below are several examples for project versioning use cases, accompanied by diagrams that illustrate them, as an end-to-end workflows.
This example shows a few cases of a developer workflow.
Create a tag, where all changes are committed and pushed and aligned with GIT.
Create a tag, where there are local changes that are not pushed to GIT. Studio, then, alerts about their presence.
However, the developer can also choose to ignore the alert and to continue with the version tagging. This is a slightly risky, yet a valid case, as the version that is about to be released should not include the features he is currently working on. In our example (depicted in the below diagram), the developer pushes his changes and re-activates the version tagging, this time without getting any alerts.
Deploy to remote server where no changes were done after creating the tag. In this case, the deployed artifacts are fully aligned with the tag, in a way that when running the version
command in the remote server, you can be assured that the version is aligned with tag artifacts.
Deploy to remote server where changes were done locally after creating the tag. In case where Warn-on-Tag-Diff is chosen in User Preferences for this remote server, Studio alerts the user. If the user chooses to proceed anyway, then the built artifacts are marked with a star (*). This way, when running the version
command in the target remote server, the user is hinted that the deployed artifacts are not fully aligned with the tagged version.
version
command on the server, you can be assured that it is aligned with tag artifacts in GIT.This example illustrates the case of several developers who work on the same project. This example starts when version 1.0.4 is created and two developers start working based on it (it is assumed that the branch is fully aligned with the tag. You can see in example 1 that it is not necessarily the case).
This is a legitimate case, where another developer continues with an implementation that is aimed for a later version. Accordingly, DEV 1 should verify, before proceeding, that DEV 2's changes shall not be part of the current version's content.
This example illustrates a required-hotfix case, where one of the developers handles the hotfix implementation, while another continues to work on the main branch, without any collisions.
When he starts developing, the GIT would detach the developer from the tag, where he would need to push his changes to a new branch.