To adapt to the prevailing trends and rules in the software world. We decided to implement semantic versioning, which we should use for a long time. This issue item will brighten further way of versioning.

Starting from the 1.0.0 version, we will implement the new meaning of version number. According to the semantic versioning rules, the next GrandNode releases will follow the specified pattern - X.Y.Z Where X is a MAJOR release, Y is a MINOR release and Z is a PATCH release.

So our incoming version will be 1.0.0 and 1.0.0-beta for the incoming beta version.

How we will distinct each release and what will trigger the next release? Starting from the beginning, the MAJOR release will be strictly related to technological changes. For example, 2.y.z will be released when we will implement the .NET Core 6 to the project. In the MINOR releases, you will find changes related to the application functionality. For example - we want to implement the Voice Virtual Assistant features, we would need to make a MINOR release. And finally, the PATCH releases will be the most frequent, they will contain bug fixes, tweaks in the CSS, CSHTML files. There is an important requirement, that changes in PATCH releases cannot interfere with the application's source code.

The update frequency is as follows: MAJOR only when a major upgrade related to .NET Core, MongoDB, or other technology that GrandNode uses, changes are required. We are unable to predict how often. MINOR every six months. PATCH much more often, not less than once a month. Importantly, the release of the new PATCH version will not require uploading new plugins. NuGet Packages will be updated only in MINOR and MAJOR releases.