In general, the benefits of using a versioning system are more relevant when you are a team. In fact, versioning increases the potential for simultaneous works and improves version tracking and synchronization over time. Also, you can easily manage the versions history. You can forget the multiple files stored in different places, named “final version 1”, “final version 2” and so on. Enough, you deserve a solution that allows you to manage your versions with ease.
What is a version?
A version concerns everything that has a progression in computing : an application, a product, an OS… The version defines the progress of a product. It is written this way: X.Y.Z, for example 1.0.8.
In GIT, we can identify two potential references: tag or branch. A tag marks a point in time that must not change. Conversely, a branch is evolving (potentially). It means only the tag can be a stable version of a software. But, we can use unstable versions, mainly during the development stage.
Versions materialize different phases of software development: Dev version: the version is under development. No stability is guaranteed. Alpha version: the version is being developed but tested internally. This stage is usually used as a POC (Proof of Concept) to validate general operation. Beta version: the version is open to a restricted audience, which can raise problems. RC (Release Candidate) version: the version is open to a restricted public, but should normally no longer contain bugs. Stable or final version: the version is open to the public and is supposed to contain no more bugs.
Semver: identify the main evolutions of your software
Semver means semantic versioning. It is a semantic version management, a logical and consistent way to number versions. It is not a standard but it tends to be.
X.Y : Version.Revision
The version is the functional breakdown of a software at a given time (like a snapshot). The revision is a status of a functional batch. The first official release will be identified as version 1.0. In case of corrections, these evolutions will be released under version 1.1. This means we keep the same features but with corrections or upgrades. The second official release will be named version 2.0 (even if the first one is version 1.3). This process continues until the software gets all its desired features.
X.Y.Z : Major Version.Minor Version.Revision
This kind of versioning is useful when you have many features in a project. It is the same concept than above with the difference that we add criticality. To prioritize and sort the different features, we then talk about major and minor versions. How do we create versions in GenMyModel? GenMyModel online tool helps you diagramming directly through your web browser. No install, no set up and no learning curve to get started. With this tool you can easily manage versions of your diagrams. Here is how you can do it.
- Choose your diagram by default
- Create a package
- Once your diagram is finished, save this version and go on the dashboard
- Click on “Versions” (only in the Enterprise Plan)
You can view the version, only in “read only” mode. It’s a snapshot of your model at one point time.
How to restore a version?
- Go to your dashboard
- Select the project
- Click on “Restore” under the version concerned
You can also:
- Go back to the editor and access history (tools)
- Green pins materialize your versions, click one to back to this version
In history mode, you can go back and forth to multiple versions, saved as an official version or not.
Versioning is definitely a very useful way to collaborate within a project. Architects can then give developers access to an up-to-date version without giving them access to the current state. We can even imagine giving access to these versions to an external person. We are currently working on the possibility of merging two versions. Would that be a feature that would interest you?