Script/Function Versioning

Welcome Forums General PowerShell Q&A Script/Function Versioning

This topic contains 5 replies, has 3 voices, and was last updated by

 
Participant
8 months, 2 weeks ago.

  • Author
    Posts
  • #95532

    Participant
    Points: 0
    Rank: Member

    Does anyone have a good approach to versioning of PowerShell scripts and functions? It would simple if "VERSION" was a command-based help keyword, then the version number could be easily auto-updated via CI pipeline or build task.

    Basically trying to introduce proper versioning of all functions in a solution, and also have the version easily retrievable for diagnostics/logging purposes.

    Cheers,
    Dave.

  • #95552

    Keymaster
    Points: 1,638
    Helping HandTeam Member
    Rank: Community Hero

    That's what a manifest is for! Easily updated via code. Do it all the time.

    • #95561

      Participant
      Points: 0
      Rank: Member

      Hi Don. Sorry, should have been clear. I'm using a modular approach with private and public functions (each function is in its own .ps1 file). So the module itself has a manifest with versioning, but the goal is to have more granular versioning down to the function level.

      Maybe doing it at manifest level of the module may work. Just be nice to do a Get-Command on a module and not have all the functions listed as version 1.0.

  • #95568

    Keymaster
    Points: 1,638
    Helping HandTeam Member
    Rank: Community Hero

    PowerShell's ethos is that a module is the most granular unit of versioning and distribution. If you're wanting to do anything more granular, then you're more or less on your own, and working outside the shell's native stuff. The reason it's at the module level is because that's what gets distributed to people; internally, for more granularity, Microsoft itself relies on their version control system if they need to retrieve previous versions, and refers to them by those builds. But an individual function isn't seen as a standalone unit of work.

    The most I can think of is a comment-based help field that you repurpose, or a private hashtable within each .ps1 that you put your own metadata into.

    Personally, I've not taken this approach of a function-per-.ps1; a module is usually one .ps1 for me, and I test the whole thing. My tests are tagged, so if I know I only need to test a certain function, then I just have Pester test only the tests with that function's tag.

  • #95571

    Participant
    Points: 13
    Rank: Member

    A couple of thoughts. You could use git as a source control but if you want proper source control you would have to use the likes of visual sourcesafe (others are available)

    But the following links you may find useful

    https://blogs.technet.microsoft.com/dsheehan/2017/07/27/maintaining-version-control-over-distributed-powershell-scripts/

    https://blogs.technet.microsoft.com/heyscriptingguy/2012/12/28/protect-your-powershell-scripts-with-version-control/

    • #95574

      Participant
      Points: 0
      Rank: Member

      All the code is already in git (well VSTS). One of the main goals is when the code is executing the detailed logs include the version of the scripts and functions. And ultimately those versions will track back to to a check-in and successful unit testing.

      But maybe updating the module version is the way to go, even when the check-in may be a single change in a single function.

The topic ‘Script/Function Versioning’ is closed to new replies.