2

I am looking for a 1-liner that looks something like this:

(gitversion | ConvertFrom-Json).SemVer.split('.') | [string]::Format("{0}.{1}.{2}",$_[0],$_[1] + 1,$_[2]) | git tag $_

So, right now I have 0.1.0 and I want a 1 liner that will map it to: 0.2.0

I am sure a guru in PS can make fast work of this

Christian Bongiorno
  • 5,150
  • 3
  • 38
  • 76
  • 6
    Powershell actually knows what version numbers are ... `'0.2.0' -as [VERSION]`. This way you can correctly calculate with version numbers or compare them properly ... – Olaf Feb 15 '20 at 18:52

3 Answers3

4

You can read in the entire json, use the Major, Minor and Patch number of the version and update whichever one you are interested in... patch, minor or major.

I am using foreach-object to access all the properties of the json even though there is only one available. 1-liner:

gitversion | ConvertFrom-Json | % { "$($_.Major).$($_.Minor + 1).$($_.Patch)" } | % { git tag $_ }

How can % / ForEach-Object work with multiple repositories

If there is only one repository at the path you are running gitversion, it will always give you one object. (gitversion fails with errors when you run this in directory that doesnt have a git repository.)

I would like to stress that this would work great in your scenario where there is only Major, Minor and Patch version. In cases where the SemVersion is like, "SemVer":"0.1.0", this is fine. But, if your interest is to keep the PreReleaseTag as well in your next version (and not drop the alpha / beta etc tags), you can include the PreReleaseTagWithDash to your output as well. e.g of pre-release tags: "SemVer":"0.1.0-alpha.915"

gitversion | ConvertFrom-Json | % { "$($_.Major).$($_.Minor + 1).$($_.Patch)$($_.PreReleaseTagWithDash)" } | % { git tag $_ }

Sample JSONs of gitversion

  • From dev or other branches, you can expect variations in semVer that includes pre-release tags.
{
  "Major":0,
  "Minor":1,
  "Patch":0,
  "PreReleaseTag":"alpha.915",
  "PreReleaseTagWithDash":"-alpha.915",
  "PreReleaseLabel":"alpha",
  "PreReleaseNumber":915,
  "WeightedPreReleaseNumber":915,
  "BuildMetaData":"",
  "BuildMetaDataPadded":"",
  "FullBuildMetaData":"Branch.dev.Sha.888xxx.xxx888",
  "MajorMinorPatch":"0.1.0",
  "SemVer":"0.1.0-alpha.915",
  "LegacySemVer":"0.1.0-alpha915",
  "LegacySemVerPadded":"0.1.0-alpha0915",
  "AssemblySemVer":"0.1.0.0",
  "AssemblySemFileVer":"0.1.0.0",
  "FullSemVer":"0.1.0-alpha.915",
  "InformationalVersion":"0.1.0-alpha.915+Branch.dev.Sha.888xx.xx888",
  "BranchName":"dev",
  "Sha":"888xx.xx888",
  "ShortSha":"7a1152f",
  "NuGetVersionV2":"0.1.0-alpha0915",
  "NuGetVersion":"0.1.0-alpha0915",
  "NuGetPreReleaseTagV2":"alpha0915",
  "NuGetPreReleaseTag":"alpha0915",
  "VersionSourceSha":"88xxx.xx88",
  "CommitsSinceVersionSource":915,
  "CommitsSinceVersionSourcePadded":"0915",
  "CommitDate":"2019-12-06"
}
  • From master branch, you would normally expect a semver = major.minor.patch.
{
  "Major":0,
  "Minor":1,
  "Patch":0,
  "PreReleaseTag":"",
  "PreReleaseTagWithDash":"",
  "PreReleaseLabel":"",
  "PreReleaseNumber":"",
  "WeightedPreReleaseNumber":"",
  "BuildMetaData":0,
  "BuildMetaDataPadded":"0000",
  "FullBuildMetaData":"0.Branch.master.Sha.9999xxx....xxx999",
  "MajorMinorPatch":"0.1.0",
  "SemVer":"0.1.0",
  "LegacySemVer":"0.1.0",
  "LegacySemVerPadded":"0.1.0",
  "AssemblySemVer":"0.1.0.0",
  "AssemblySemFileVer":"0.1.0.0",
  "FullSemVer":"0.1.0+0",
  "InformationalVersion":"0.1.0+0.Branch.master.Sha.999xxx...xxx999",
  "BranchName":"master",
  "Sha":"86b0be929a84ba7e9b2a463e7dbdc9a3c9325dc1",
  "ShortSha":"86b0be9",
  "NuGetVersionV2":"0.1.0",
  "NuGetVersion":"0.1.0",
  "NuGetPreReleaseTagV2":"",
  "NuGetPreReleaseTag":"",
  "VersionSourceSha":"999xxx...xxx999",
  "CommitsSinceVersionSource":0,
  "CommitsSinceVersionSourcePadded":"0000",
  "CommitDate":"2018-02-18"
}

NOTE: I have not tested this with multiple git repositories in one location. This solution will work if there is only repository at the path you are running.

Jawad
  • 11,028
  • 3
  • 24
  • 37
3

Note: The solutions below assume that a string representation such as 0.1.0 is to be parsed; as it turns out, the JSON that utility gitversion outputs has individual version-number components such as Major, Minor, ..., which Jawad's answer relies on; however, even utilizing the individual properties for synthesizing an output string can be challenging, if all semver version components are to be preserved.


For a solution that is both robust and convenient, use the [semver] (System.Management.Automation.SemanticVersion) type that PowerShell [Core] 6+ offers (command is spread across multiple lines for readability):

You can simply cast a version string such as 0.1.0 to [semver], yielding an object with numeric .Major, .Minor, and .Patch properties, alongside others; you can construct a new [semver] instance from it, with the modified minor version and all other properties passed through:

(gitversion | ConvertFrom-Json).FullSemVer | foreach { 
   $v = [semver] $_;
   [semver]::new($v.Major, ($v.Minor+1), $v.Patch, $v.PreReleaseLabel, $v.BuildLabel) 
  } | foreach { 
        git tag $_ 
      }

foreach is the built-in alias for the ForEach-Object cmdlet.
What the first foreach command outputs is a [semver] object, not a string, but passing such an object implicitly stringifies it, which yields the desired representation.

The above ensures that all components of a semver-compliant version string are preserved on output, notably including the pre-release and build-metadata fields, if present (e.g.,
1.0.0-alpha+001).


If your version-number strings are always composed of 2 - 4 numeric-only components (e.g., 1.0, 1.0.2, 1.0.2.10), you can use the [version] type (System.Version) instead, which is also available in Windows PowerShell (PowerShell versions 5.1 and below):

'0.1.0.34' | foreach { 
    $v = [version] $_; $newMinor = $v.Minor + 1
    if ($v.Build -ne -1 -and $v.Revision -ne -1) { [version]::new($v.Major, $newMinor, $v.Build, $v.Revision) }
    elseif ($v.Build -ne -1) { [version]::new($v.Major, $newMinor, $v.Build) }
    else {[version]::new($v.Major, $newMinor) }
   } | foreach { 
        git tag $_ 
      }

Note the - unfortunate - need to use [version]'s various constructor overloads selectively, which is the consequence of a design asymmetry: non-specified version components (for the optional build and revision fields) default to placeholder -1, but passing these placeholders to the 4-component constructor is not supported.


Note: The advantage of the above solutions is that you get proper object representations of the version numbers, which make programmatic processing easier in general.

  • However, it is baffling that neither [semver] nor [version] themselves offer methods for incrementing the version numbers they represent.

If all you need is the string representation of the modified version number, a concise regex-based based text-parsing solution is possible too, which again PowerShell [Core] 6.2+ makes easier, because the regex-based -replace operator there supports script-block-based substitutions (see the linked answer for how to do it in Windows PowerShell):

(gitversion | ConvertFrom-Json).FullSemVer | foreach { 
   $_ -replace '(?<=^\d+\.)\d+(?=.*)', { 1 + [int] $_.Value }
  } | foreach { 
        git tag $_ 
      }

Variations of the regex for incrementing the 3 version-number components (trailing pre-release and build labels would be preserved):

  • the major number (e.g., 2.0.9 -> 3.0.9):

    • '2.0.9' -replace '\d+(?=\..+)', { 1 + [int] $_.Value }
  • the minor number (as above; 2.0.9 -> 2.1.9)):

    • '2.0.9' -replace '(?<=^\d+\.)\d+(?=.*)', { 1 + [int] $_.Value }
  • the patch number (third component; 2.0.9 -> 2.0.10):

    • '2.0.9' -replace '(?<=^\d+\.\d+\.)\d+(?=.*)', { 1 + [int] $_.Value }

Caveat: The assumption is that the targeted version component is present in the input string; e.g., trying to increment the patch component in input string '2.0' would not work; this fragility is another reason to prefer an object-based approach via [semver].

mklement0
  • 382,024
  • 64
  • 607
  • 775
1

If I understand this right, you want to add 1 to the 2nd number. I wish I could do $a.minor += 1, but the [version] type is read-only.

$a = '0.1.0'
$nums = $a.split('.')
'{0}.{1}.{2}' -f $nums[0], ([int]$nums[1] + 1), $nums[2]

0.2.0

Or

$a = '0.1.0'
$nums = $a -split '\.'
([int]$nums[1])++
$nums -join '.'

0.2.0

Or

$a = '0.1.0'
$nums = $a.split('.')
([int]$nums[1])++
'{0}.{1}.{2}' -f $nums

0.2.0

I was also trying the ps 6 version of -replace with the scriptblock, but it became challenging.

See also Increment version in a text file

Here's another one, but it needs powershell 6 for the -replace with a scriptblock. I'm using regex with positive lookahead and positive lookbehind, so I'm only replacing the number and not the 2 dots on each side. This would only work with 3 numbers, unless you wanted to increment 2 middle numbers by 1, lol. It certainly qualifies as a one-liner.

'0.11.0' -replace '(?<=\.)\d+(?=\.)', { [int]"$_" + 1 }

0.12.0


'0.11.11.0' -replace '(?<=\.)\d+(?=\.)', { [int]"$_" + 1 }

0.12.12.0
js2010
  • 23,033
  • 6
  • 64
  • 66