Feedback: Option to auto-increment solution version when exporting

[adhishrajgupta]

I am not sure if there is a way to auto-increment the solution version using pac solution export command. When exporting a solution from the UI, the UI shows an experience where the solution version is automatically set to one higher version.

It will be helpful to be able to do something similar using the CLI. In an ALM strategy where multiple developers are pushing updates to a master solution, the ability to auto-increment the solution version at the time of exporting can be quite useful because with that ability once the solution is exported out and unpacked, it will make it easier to version the solution, check-in to source control and deploy to upstream environments. Please let me know if you would like to discuss for further clarity.

[davidjenni]

@adhishrajgupta this already exits, but right now as a small sequence of pac CLI commands. The CLI already has a pac solution version which mutates a local solution.xml, and remembers the last e.g. patch version in either:

• git tags
• a separate .csv file
• or within the solution.xml itself (the latter 2 files would need to be committed to the repo).

So this could be scripted as (pls refer to the pac CLI builtin help for each of the actual commands and its parameters):

pac solution export
pac solution unpack
pac solution version
pac solution pack
pac solution import <to other DV env>

Variation of this approach, and closer to best ALM practices we advocate, is to ensure that changes to solutions are continuously exported and unpacked to a backing git repo, keeping that repo as the source of truth.

When a particular state of that solution needs to be shared or deployed to other environments, the solution gets first version (pac solution version), then rebuilt using either msbuild of a .cdsproj (if your local solution has been captured via pac solution clone) or again running pac solution pack against the source of truth repo.

Final note: solution versions are NOT intended to handle concurrency between developer, but to identify states of a given solution. Any concurrency needs to be handled and addressed with on the git repo level. This will allow also diffing and resolving between conflicting versions