In the last installment, we looked at how to version the source portion of your projects; in this new article we will explore how to version the “executable” part of your project. This is comparable to the individual version of a .c file in your SCM vs. the version of an application.

First Option

The first option to bring versioning to your project is usually to simply copy your projects and rename them by adding a version number. projA is copied into projA_v1.0, and projB is copied into projB_v1.0. It should look like:

The problem with that option is that any sub-procedure call will not resolve to the new version but to the original one. Inside ElectricCommander projA and projA_v1.0 are 2 different projects with no connection to each other. So you need to rename all your calls to projA into projA_v1.0, both for direct sub-procedures and for API calls. This is a completely manual task that is time consuming and error prone as one missed call could break your whole system.

To help, you could export your project into an XML file as we’ve seen in the last article to do a clever search and replace before reimporting your project in its new version.

Second Option

The natural evolution of option #1 is to use the power of properties, as the problem you’re facing is the version number in the project name. To accomplish that, you can create a “version” property attached to /server or a global “data” project. You modify all your sub-procedure calls to projA$:procA and projB$:procB. In your development environment, simply keep the /server/version property empty so you work directly in ProjA and ProjB. When you create projA_v2.0 and projB_v2.0 and move it to the production environment, simply set /server/version to “_v2.0”. You can even assign different version to different groups by setting /server/version to something like $/version] and setting the “version” value in each group instead. This approach works really well but require a great deal of consistency to be sure the $ is added to each sub-procedure call. In addition, if the parameters change in the sub-procedure, you need to manually change them in the caller as the UI won’t be able to link the two automatically.

Final option

The preferred method nowadays is to create plugins out of your projects and install those plugins in your production environment. The advantage of this approach is that it’s really easy to have several different versions of a plugin. The promoted version is called by default but you can always invoke a specific version if you have the need. In addition a plugin can include a help page that makes it easy to document your work and help your users to properly interact with your work. You still need to modify your call from a procedure to a plugin but this change is required only once for the life of your plugins. If you choose this option from the start, no modification will be required. The difficulty here was mostly to create a plugin automatically from a project. To help with this matter, I've added a procedure in EC-Admin 1.3.5 that is available on GitHub .

Conclusion

In this article, we explored different ways to version your projects for production use. Each has pros and cons. Our own Professional Services and Solution Architect teams have standardized on the plugins solution. We believe this approach offers the best compromise. As usual, please let me know if this topic is useful to you by leaving a comment below or contacting us directly by email .