Customer Engagement & Dynamics CRM Forum

Expand all | Collapse all

Best way to deal with version numbers in solutions?

  • 1.  Best way to deal with version numbers in solutions?

    TOP CONTRIBUTOR
    Posted Feb 26, 2019 09:37 AM
    When was that Solution v.14.8.2.2833 created or installed?

    No one knows.

    That's why I believe this is the best way to approach versioning:


    Is this how you do it today?



    ------------------------------
    Gus Gonzalez
    7x Microsoft MVP, CRMUG All-Star
    CEO, Elev8 Solutions
    ------------------------------


  • 2.  RE: Best way to deal with version numbers in solutions?

    Posted Feb 27, 2019 09:29 AM
    yyyy.mm.dd.build would work well for CRM solutions as they dont have to represent compatibility between versions (typically major.minor.revison.build, is used in software systems, as its easy to represent when a certain version has a breaking change). But, I doubt, we would see Microsoft move to such a versioning scheme for their solutions, because of the fact that it cant represent compatability/breaking changes in versions.

    Here is some good discussion on this: https://softwareengineering.stackexchange.com/a/3223/37966


    ------------------------------
    Raj Rao
    National CineMedia
    Centennial CO
    ------------------------------



  • 3.  RE: Best way to deal with version numbers in solutions?

    GOLD CONTRIBUTOR
    Posted Feb 27, 2019 09:49 AM
    Actually you can see when it was installed from the `Information` tab on the solution itself



    ------------------------------
    Nick Hance
    Principal Developer; President
    Reenhanced
    www.javascriptforcrm.com
    www.buildbettersoftware.com
    Green Lane PA
    ------------------------------



  • 4.  RE: Best way to deal with version numbers in solutions?

    TOP CONTRIBUTOR
    Posted Feb 27, 2019 10:00 AM
    Edited by Gus Gonzalez Feb 27, 2019 10:01 AM
    Hi @Nick Hance, I'm aware. :)

    But you can't see the date when the solution was created.

    So for example, you see a solution version 12.8.2.1846 installed on February 25th, 2019 in Production. Can you tell when that solution was created?

    However, with solution version 19.2.3.2 installed on February 25th, 2019 in Production, I can tell you that the solution was created in Dev on February 3rd, it was the second export of the day, and it spent 22 days in UAT.

    That's why you want to use dates in versions.

    ------------------------------
    Gus Gonzalez
    7x Microsoft MVP, CRMUG All-Star
    CEO, Elev8 Solutions
    ------------------------------



  • 5.  RE: Best way to deal with version numbers in solutions?

    GOLD CONTRIBUTOR
    Posted Feb 27, 2019 10:47 AM
    Very thoughtful, thanks for sharing!

    ------------------------------
    Nick Hance
    Principal Developer; President
    Reenhanced
    www.javascriptforcrm.com
    www.buildbettersoftware.com
    Green Lane PA
    ------------------------------



  • 6.  RE: Best way to deal with version numbers in solutions?

    SILVER CONTRIBUTOR
    Posted Feb 27, 2019 01:13 PM
    Going to be a bit controversial here, but I fundamentally disagree with this idea around versioning convention.

    The reason Microsoft give us the x.x.x.x format is that it follows best practice for software engineering standards, which is basically:

    Major.Minor.Patch.Build

    So it is easy to see at a short glance that 1.2.12.829 is very different from v2.1.1.100, but is very close to v1.2.13.2. It also allows you to specify dependencies more easily in a format independent way (remember, in the UK 1/31/2019 is not a valid date - I know in the example above you use the international format but still it's something people need to know). For example: "You need solution v1.2 or higher", not "You need a solution created on or after the 20th Feb 2019". Proper semantic versioning leads to tighter controls without this ambiguity.

    Regarding recording the dates solutions were created, I would argue this is irrelevant as best practice dictates you should be managing anything that is released as an artefact in a source code repository (i.e. a git repo, do we use anything else these days?) or artefact repository (Azure Artifacts (sic), Nexus, Artifactory) in which case the date and time these were added to the repository (along with an immutable build or commit hash/number) are automatically generated and give you much better governance over software versioning.

    The only concession I will allow is possibly to use the BUILD portion of the version number (i.e. the last number) as the date. For example:

    v1.2.3.20190115 (for Version 1.2.3 that was build on the 15th Jan 2019)

    But even this I am not in love with.

    Ta,

    Ben

    ------------------------------
    Ben Bartle
    IBM
    ------------------------------



  • 7.  RE: Best way to deal with version numbers in solutions?

    TOP CONTRIBUTOR
    Posted Feb 27, 2019 01:45 PM
    I wasn't aware this is a best practice. As far as I understand Microsoft has been using this system to set versions for Dynamics CRM/365 and they have explained how we can "read" it, but I have never heard that they recommend people use the same method, or discourage anybody from using "dates" as versions.

    But even if I had heard it 100 times, that doesn't mean anything. One thing is to have Best Practices that make sense, and the other is the real world(see Managed vs. Unmanaged).

    In the real world, setting versions following "these best practices" provides no additional value above what you can get by using dates. But using dates gives us the ability to quickly understand relevancy or age of a solution. For example, I just looked at my current XrmToolBox version and noticed the version number is 1.2018.10.29, I have to assume there has been at least 1 or 2 new releases since then. I have to update it.

    If that version number was 7.4.2.875, I would have no idea.

    Unless you are planning to match the version number of your solution, to the version number of Dynamics 365 to "show the latest version you support" I just can't see ANY value on using these "best practices" you mention.

    Using those best practices only accomplishes frustration...right now I can see that my Project Service solution from Microsoft is on version 2.4.0.51 with Field Service at 7.5.0.60 and the Sales app running on version 9.0.1810.5012...can you look at these and tell me all of these are up to date? Or when they were released or created? Each of them has it's own patch too, with the same crazy "best practice" version number.

    It makes no sense.

    You can accomplish the same "development goals" by using dates, and at least I would know when my apps were updated last, or whether I should look and see if an update is available.

    But then again, I'm not a developer, I wonder how my developer friends think about this subject.

    I'll ask them to chime in. :)

    ------------------------------
    Gus Gonzalez
    7x Microsoft MVP, CRMUG All-Star
    CEO, Elev8 Solutions
    ------------------------------



  • 8.  RE: Best way to deal with version numbers in solutions?

    SILVER CONTRIBUTOR
    Posted Feb 27, 2019 02:44 PM
    We may end up agreeing to disagree on this one :) Best practice is both fluid and open to preference of course.

    You say a standard version number is meaningless, but I would say that something like 7.4.2.875 tells you a lot. It tells me it's major version 7, minor version 4, but it's had a couple of patches. Most developers will know which features came in major and minor versions, so knowing it's 7.4 is quite a lot of value. I think this is much better than remembering a date.

    If you take the software you're working on right now, Dynamics, it uses semantic versioning. And I bet you can remember what was released in v8.2, rather than the date it was released.

    But the major thing is differences between versions. For example if I have Solution version 18.12.20 in Production, and someone wants to deploy version 19.1.15 - what is going to be deployed? It could literally be anything from a single bug fix to multiple new features! Whereas if you used my style, you would know for example if the major number had changed, there could be breaking changes, whereas a change in the patch number illustrates this is likely just a bug fix and the risk is lower.

    Google, Microsoft and most of the tech giants ALL use semantic versioning for this reason. I am a developer and I believe this is the only way to go.

    ------------------------------
    Ben Bartle
    IBM
    ------------------------------



  • 9.  RE: Best way to deal with version numbers in solutions?

    TOP CONTRIBUTOR
    Posted Feb 27, 2019 02:50 PM
    I'll chime in and support Ben's reply here as well. This is the standard we follow at Beringer Technology Group both internally with our own CRM system as well as how we handle them for Customers. For us, it has worked well. :)

    ------------------------------
    Heidi Neuhauser
    Beringer Associates, Inc.
    Green Lane PA
    ------------------------------



  • 10.  RE: Best way to deal with version numbers in solutions?

    GOLD CONTRIBUTOR
    Posted Feb 27, 2019 04:07 PM
    Edited by Nick Hance Feb 27, 2019 04:15 PM
    Hey everyone:

    This argument is invalid. You must support semantic versioning if you are following best practices and systematically Dynamics cannot support date releases.

    Here's why:

    If you're using date-based numbering, how can you release patches to your solutions that aren't done in the current month?

    If you aren't using patches, how are you managing your solution development?
    Without patches, how can you know what is changed between what is deployed, and what you're releasing?

    I have many more thoughts around this and and we're developing a tool for automatic source repository management of solution updates. We already have a system internally that we follow to manage all of our production solutions within source code repositories because it can be so dangerous to not have a clear picture of what's going to production.

    ------------------------------
    Nick Hance
    Principal Developer; President
    Reenhanced
    www.javascriptforcrm.com
    www.buildbettersoftware.com
    Green Lane PA
    ------------------------------



  • 11.  RE: Best way to deal with version numbers in solutions?

    Posted Feb 27, 2019 04:43 PM
    Edited by Raj Rao Feb 27, 2019 06:27 PM
    When you are cloning a patch, you would no longer use the date-version.
    Say your solutions first version is: 2019.02.28.01
    Next month you create a new version: 2019.03.10.01
    A few months later a customer on 2019.02.27.01 version finds an issue. When you clone a patch, you would just make it 2019.02.29.01 or 2019.02.29.02. Patches, need to be tracked to the original solution from where they came and this does it nicely.

    Again, this thread is a good read: https://softwareengineering.stackexchange.com/a/3223/37966. Date based versioning works really well if you are working with solutions for your own org and dont utilize patches, etc. If you provide solutions (eg: through the market-place, etc), then, it might not work all that well for you.

    Even though, we dont use this type of versioning for CRM, we do use this for many internal applications that we deploy on a regular basis. Its nice to know exactly when the app build was created, and if a test environment is out of date, without looking up some spread-sheet.

    Also, there is this post from Jeff Atwood (CodingHorror): What's In a Version Number, Anyway?
    "Whenever possible, use simple dates instead of version numbers, particularly in the public names of products. And if you absolutely, positively must use version numbers internally, make them dates anyway: be sure to encode the date of the build somewhere in your version number."

    ------------------------------
    Raj Rao
    National CineMedia
    Centennial CO
    ------------------------------



  • 12.  RE: Best way to deal with version numbers in solutions?

    GOLD CONTRIBUTOR
    Posted Feb 27, 2019 04:49 PM
    Edited by Nick Hance Feb 28, 2019 10:19 AM
    Great insight Raj, thank you!

    In practice, this can work as long as we're all consistent with our work.

    It does sound like there's always some question about what is in production versus what is in various development environments. Is anyone else feeling this pain of not being sure what's released and what is not?

    ------------------------------
    Nick Hance
    Principal Developer; President
    Reenhanced
    www.javascriptforcrm.com
    www.buildbettersoftware.com
    Green Lane PA
    ------------------------------



  • 13.  RE: Best way to deal with version numbers in solutions?

    TOP CONTRIBUTOR
    Posted Feb 27, 2019 10:29 PM
    I can argue both sides of this issue. I believe it depends on the clients environment.

    For the smaller clients with no integration, I think there is value in @Gus Gonzalez's suggestion because end users can easily comprehend it and it adds value to them. A solution file can have literally anything in it and the (typical) version number does nothing to help you with figuring out what is major/minor/patch or resolving dependencies. By using Gus's technique, the date of the solution is built into the exported file name. By using Gus's technique, you avoid having multiple copies of a file called "SolutionName_1_0_0_0.zip" and trying to figure out which one is relevant. I would argue that for the people creating solutions for small(er) organizations, it is not easy to make the distinction of major vs minor. Can anyone here define how many fields on a form must move before you cross the threshold from a patch to a minor release, or how many business rules must be changed before it becomes a major release?

    But for a company that has a staff of developers that depend on integration with other systems and have governance policies, we should consider the benefits to the version number with a traditional approach. For many of my past projects, I have clearly agreed with @Ben Bartle's position because I come at this as a developer. The reason has to do with traditional software development practices: When writing applications that have dependencies on a multitude of libraries (.DLL's), then keeping track of the version number helps you identify whether an update to a library will significantly impact your application. With a DLL it is easy to define what is major, minor or a patch based on best practices.

    To bring this point back into context of this discussion, when you modify a solution and then promote it to production, you are actually updating the API endpoints. Consider what happens when you alter the behavior of workflows, deprecate entities/fields, or make the field length shorter. When you promote that solution into production, you run the risk that integration code will break.

    Personally, I have been putting the date in the solution's Information/Description field. The only downside with that approach is that you have to either import the file to see the date, or rip apart the zipped solution file. While this is not as pretty as using the version number as a proxy for a date, it serves it purpose because you can see the solution description gets updated in the production system.

    With respect to keeping track of whether the solution file contains a major/minor/patch to a system, that is something everyone should be documenting anyway regardless of whether you go with Gus or Ben's recommendation. By keeping a log of changes and/or implementing a full version control system between development/staging/production, you must be communicating your changes to your testing staff or your end users, no matter how small the change is. If users detect a change that you were not in control of, they might think the system is unstable, and they will lose confidence in your system.


    ------------------------------
    If this answered your question, please click on the arrow button next to Reply Inline and choose 'Make Best Answer.'
    Thanks.
    Nelson Johnson, Solution Architect
    BroadPoint, Inc., Bethesda MD
    Link with me! https://www.linkedin.com/in/nelsonjohnson/
    ------------------------------



  • 14.  RE: Best way to deal with version numbers in solutions?

    SILVER CONTRIBUTOR
    Posted Feb 28, 2019 04:29 AM
    Wow, I didn't expect to trigger so much debate. Really good to hear everyone's views.

    @Nick Hance what does good look like for you in terms of this automation? I've been working on a lot of tooling around this for ages, and my holy grail is a service that can easily be provisioned that does the following every time a solution version number is changed:

    1) Detect the change and compare it to the solution version currently committed to a particular repo
    2)​ If the solution number has changed, export both managed and unmanaged, and overwrite the existing zip files in the repo
    3) Using SolutionPackager, extract the unmanaged solution to a subdirectory
    4) Take the first line of the Solution Description (from Dynamics) and use that as the commit message, commiting the zips and unpacked files to the repo
    5) Update the first line of the Solution Description (from Dynamics) and append the commit hash to the line.

    This means

    a) All a developer needs to do to promote a solution (all the way to production potentially if you've configured a proper CI/CD pipeline) is to add a line to the description and bump the version number in Dynamics (i.e. they don't need VS, don't need to understand git)
    b) You automatically get a change log (with the git commit hashes) in the solution description.

    Whether there is a market in this I am doubtful, but this has never stopped me in the past :)

    What would make this a million times easier is if:

    a) They enabled the UPDATE message on the Solution Entity (it wasn't an option last time I checked)
    b) They released the source code to SolutionPackager.exe - so I could port this over to .NET Core and use it inside a Docker container.


    ------------------------------
    Ben Bartle
    IBM
    ------------------------------



  • 15.  RE: Best way to deal with version numbers in solutions?

    TOP CONTRIBUTOR
    Posted Feb 28, 2019 08:13 AM
    Edited by Rex Kenley Tan Feb 28, 2019 08:23 AM

    Mitch Denny wrote on this subject and I agree with him, particularly with DevOps CI.

    https://mitchdenny.com/dates-in-version-numbers/


    The most obvious weakness of a calendar system is that you can't have numbers beyond 12, 31, 24.

    If dates are that important, Mitch did mention this convention.

    [major].[minor].[last two digits of year][day of year number].[increment]

    "I'd encourage you to start paying more attention to the way that you produce your version numbers and what information they are really giving you. Dates and times are certainly informational but aren't an accurate indicator of where something came from." - Mitch Denny.


    ------------------------------
    Rex Kenley Tan, MCP
    Tallmadge OH
    https://www.youracclaim.com/users/rex-kenley-tan

    *Always be CURRENT with JavaScript & C#, NEVER be obsolete.

    DISCLAIMER: All views expressed on this site are my own and DO NOT represent the opinions of ANY entity whatsoever with which I have been, am now, or will be affiliated.
    ------------------------------



  • 16.  RE: Best way to deal with version numbers in solutions?

    GOLD CONTRIBUTOR
    Posted Feb 28, 2019 10:19 AM
    Hi @Ben Bartle,

    Your idea is quite similar to the service we're building. It looks like this:

    1. Each solution to be monitored has a flag turned on for recording
    2. Every time a change is published, we look to see if the resource modified is inside a solution we're watching. If so, we use the `ExportSolution` action to grab a copy of the solution, unmanaged. Ideally we want this to happen in the background, automatically for every change published.
    3. The solution files are just zip files with mostly xml and some binary files. So we expand the .zip file and beautify all of the XML with a consistent process
    4. The processed and expanded solution is added as a commit in the existing git repository for the solution
    - Each different environment maintains a separate branch within the same repository. This makes comparing ​solutions highly technical, but easy to do.
    5. The solution can be converted back into an importable version just by zipping a clone of the repository at any point. If you want it managed, you need to export that from within Dynamics yourself.

    The end goal is to make this user friendly. That means reverse engineering the solution system a little so we can export the difference between any two points on a solution as a solution patch so it can be analyzed within Dynamics. That's likely not to happen for a while yet, so you'd have to make due with the raw xml diff which is still surprisingly useful.

    We already follow this process on the solutions we create for clients, though it is not fully automated. It makes it easy to get a full sense of what has changed between any 2 solutions, but the XML is hard to read and usually contains a lot of noise (numbering changes for example if you change the order of something.) The real win is in being able to summarize the changes, but it's hard to make a business case for heavy investment here if you're not Microsoft.

    What I like about this is that we can maintain our high quality standards and do "code review" before releasing updates to production. It also makes it possible to work on the same solution file in multiple environments so people aren't stepping on each other's toes, however merging conflicts can be extremely painful.

    Quality is vitally important. Our clients are investing hundreds of thousands to millions of dollars in these systems and we believe that requires full quality control systems.

    ------------------------------
    Nick Hance
    Principal Developer; President
    Reenhanced
    www.javascriptforcrm.com
    www.buildbettersoftware.com
    Green Lane PA
    ------------------------------



  • 17.  RE: Best way to deal with version numbers in solutions?

    TOP CONTRIBUTOR
    Posted Feb 28, 2019 11:57 AM
    Wow.  This thread went a bit crazy.  I think they key is to be consistent for a particular project or team.  So it doesn't matter, if it works for you and your team, then great, keep doing that.  Make sure its part of your teams standards and everyone follows it.

    Personally, I have been using dates.  When @Gus Gonzalez and a few of use were recording these, we were chatting about common Dynamics CRM/365 annoyances like "new_", gear icons and solutions that were all 1.0.0.0.  So we just chatted about what formats we follow.

    What I like about yyyy.mm.dd.hhmm is that it always increments up (so even updates in the same day will be a slightly higher version).  Administrators, functional consultants, project managers etc. can easily make sense of it.

    From a dev perspective, I have a Powershell function in my tools that will update the version based on the system date, that in itself is a lot easier than ​​having the script try to first read the existing version number and then need to prompt the user if its a major, minor or other build to know what number to increment.​  My script pulls the date and plugs it in to the solution.  easy-peasy.

    So in code: Tabs or Spaces ?


    ------------------------------
    Nick Doelman
    Microsoft MVP
    Dynamics 365 Specialist
    ottawa ON
    ------------------------------



  • 18.  RE: Best way to deal with version numbers in solutions?

    SILVER CONTRIBUTOR
    Posted Feb 28, 2019 03:28 PM
    "So in code: Tabs or Spaces ?"

    Calm down sir, do you want to start a riot?!

    ------------------------------
    Ben Bartle
    IBM
    ------------------------------



  • 19.  RE: Best way to deal with version numbers in solutions?

    TOP CONTRIBUTOR
    Posted Mar 01, 2019 07:27 AM
    ***IN JEST***

    "So in code: Tabs or Spaces ?"

    Amateurs! Minified FTW!!

    ------------------------------
    Rex Kenley Tan, MCP
    Tallmadge OH
    https://www.youracclaim.com/users/rex-kenley-tan

    *Always be CURRENT with JavaScript & C#, NEVER be obsolete.

    DISCLAIMER: All views expressed on this site are my own and DO NOT represent the opinions of ANY entity whatsoever with which I have been, am now, or will be affiliated.
    ------------------------------



  • 20.  RE: Best way to deal with version numbers in solutions?

    TOP CONTRIBUTOR
    Posted Mar 01, 2019 07:39 AM
    I think it depends on the Project and Organization. There are a lot of good suggestions here, my preference is that the version number should mean something to and not just be the next increment.   We use a format [Major].[CRMVersion].[sprint].[build] currently, because we're in the middle of a migration.  So with any solution in the system I can look at the version and know what sprint it was built in and the CRM version it was built on. Which for our organization currently is a big value add.

    Fantastic thread.

    ------------------------------
    Todd Mercer
    Dynamics CRM Technical Lead
    MD Financial Management
    Ottawa ON
    ------------------------------



  • 21.  RE: Best way to deal with version numbers in solutions?

    TOP CONTRIBUTOR
    Posted Mar 01, 2019 03:08 AM
    I think the @Gus Gonzalez approach requires more discipline than the standard semantic versioning approach.
    If the date information is important (not sure why), you could keep a log in the solution description.

    BUT - the solutions history feature that just recently surfaced probably makes it somewhat redundant.



    ------------------------------
    Donal McCarthy
    BrightWork
    Galway
    ------------------------------



  • 22.  RE: Best way to deal with version numbers in solutions?

    GOLD CONTRIBUTOR
    Posted Mar 01, 2019 09:39 AM
    I'm a sole developer at Trek and only work with unmanaged solutions most of them are marked 1.0.0.0.

    Typically I have two types of solutions that I'll be working on.
    1. Surgical solutions
    2. Big project solutions

    Versioning really only matters on the big project solutions and primarily to know if I've made a small change and pushed it to production.

    Why I'm writing this is that what I've found very helpful is tying back the name of the solution with a particular JIRA project.  JIRA provides the details of what I was working on and I tie that back with the surgical solution that I'm working on.

    I can provide quick surgical updates daily.


    ------------------------------
    Travis Judd
    CRM Developer
    Trek Bicycle Corporation
    WATERLOO WI
    ------------------------------



  • 23.  RE: Best way to deal with version numbers in solutions?

    TOP CONTRIBUTOR
    Posted Mar 05, 2019 10:59 AM
    Donal, the solution history is not going to help because it only tells you when something was imported. The issue is knowing what a solution contains based on when it was exported from the source system.

    ------------------------------
    If this answered your question, please click on the arrow button next to Reply Inline and choose 'Make Best Answer.'
    Thanks.
    Nelson Johnson, Solution Architect
    BroadPoint, Inc., Bethesda MD
    Link with me! https://www.linkedin.com/in/nelsonjohnson/
    ------------------------------



If you've found this thread useful, dive deeper into User Group community content by role