Deployment Version Best Practices

0
When deploying applications, what is the best practice for specifying a Version Number?  We have 4 environments that are deploying to:   Development Test Stage Production  
asked
2 answers
2

Hi Mike,

 

Version number is consisted of three parts: major, minor and patch. (MAJOR.MINOR.PATCH)

 

Major: Increment every time you deploy architecture changes, or changes that require work adjustment

-converting to React client

-domain model changes

-updating/adding new modules 

-upgrading to a LTS/MTS studio pro version 10.x → 11.x

 

Minor: new feature that doesn't break any existing flow in the application

-upgrade to a new minor version of Studio Pro and gain new features 10.7 → 10.8

 

Patch: fixing performance issue

- 10.7.0 → 10.7.1

 

Hope that helps as an initial idea and depending on your case , you can make your own decisions. 

answered
1

The environment doesn't matter (in this sense of the word), neither does anything else really. Usually the major number only changes with very big changes or feature releases. The minor number changes every normal release that hits production and the patch number changes if you have to release a fix in between. But that's just one way to go and it also happens to be what Mendix uses for their Studio Pro releases. You'll have noticed that browsers change their major number every normal release nowadays, meaning we're already on Firefox 144 now for example. There are also products that have no logical release numbering system whatsoever, so you can basically just do what you want. Ubuntu uses a year dot month system semiannually, going from 25.04 to 25.10 to 26.04 next year, with 4.10 being their first release back in the day. Be as quirky or as straightforward as you wish, although Mendix will autofill the highest past release numbers as "latest", so it would make sense to follow a "normal" versioning scheme I guess.

answered