{"id":3000,"date":"2019-10-08T12:33:11","date_gmt":"2019-10-08T00:33:11","guid":{"rendered":"https:\/\/www.deltics.co.nz\/blog\/?p=3000"},"modified":"2019-10-11T09:35:51","modified_gmt":"2019-10-10T21:35:51","slug":"versioninfo-and-semantic-versioning","status":"publish","type":"post","link":"https:\/\/www.deltics.co.nz\/blog\/posts\/3000\/","title":{"rendered":"VersionInfo and Semantic Versioning"},"content":{"rendered":"[Estimated Reading Time: <\/span> 8<\/span> minutes]<\/span><\/span>\n

A key step in the evolution of duget<\/strong> is an auto-update mechanism for the duget<\/strong> client itself. Going hand-in-hand with that is a need for reliable identification of the version of the client in use and any newer versions that may be available. In taking this step I have run into a minor problem caused by the constraints<\/a> in place for VERSIONINFO<\/a> resources of Windows executables.<\/p>\n\n\n\n\n\n\n\n

For duget<\/strong> packages themselves I have adopted Semantic Versioning<\/a>, but the more traditional Windows version numbers in a VERSIONINFO<\/code> resource has a number of restrictions which make them incompatible with the Semantic Version<\/strong> scheme (as discussed in some depth in this article<\/a>).<\/p>\n\n\n\n

These constraints extend also (with some variations) to Assembly versioning and MSI installers, so this is not solely a ‘legacy’ problem. <\/p>\n\n\n\n

Put simply, a VERSIONINFO<\/strong> version number is limited to an entirely numeric format with four components to the version. There is no formal<\/em> specification for what these four values represent, only different conventions, but for the purposes of this post we’ll use:<\/p>\n\n\n\n

Major.Minor.Revision.Build<\/code><\/p>\n\n\n\n

Each of these values is limited to a maximum value as follows:<\/p>\n\n\n\n

255.255.65534.65534<\/code><\/p>\n\n\n\n

Semantic Versioning by contrast supports only three numeric components, referred to as:<\/p>\n\n\n\n

Major.Minor.Patch<\/code><\/p>\n\n\n\n

Semantic Versioning also caters for zero or more alpha-numeric identifiers<\/strong> and a further zero or more items of build meta-data<\/strong>.<\/p>\n\n\n\n

Major.Minor.Patch-<identifiers>+<build meta-data><\/code><\/p>\n\n\n\n

Identifiers<\/strong> are used to identify pre-release versions and are significant in determining version precedence. Build Meta-Data<\/strong> is entirely documentary in nature and plays no part in version precedence.<\/p>\n\n\n\n

I am not currently generating or using Build Meta-Data<\/strong> at all so we won’t be mentioning that again in this post.<\/p>\n\n\n\n

\n\n\n\n

As mentioned in earlier posts<\/a>, I am using GitVersion<\/strong> to automatically derive a Semantic Version<\/strong> for my packages based on a combination of a specified version in a GitVersion.yml<\/code> configuration in each project combined with the branch and commit history in the repository at the time of the build.<\/p>\n\n\n\n

For duget<\/strong> packages this works well as the Semantic Version<\/strong> is simply recorded as meta-data in the .duspec<\/code> manifest for the package, which is a simple JSON file, as well as in the filename of the package itself.<\/p>\n\n\n\n

When building an executable ideally the Semantic Version<\/strong> would carry forward into the VERSIONINFO<\/strong> of the exe<\/em> produced by the build. But this is where we run into a problem.<\/p>\n\n\n\n

A pre-release build of the duget<\/strong> exe<\/em> might have a Semantic Version<\/strong> similar to:<\/p>\n\n\n\n

0.1.0-alpha.15<\/code><\/p>\n\n\n\n

The first three fields are no problem as we can simply use these for Major.Minor.Revision<\/code>. But there is no way to represent the alpha-numeric pre-release identifier in the numeric Build<\/code> field of a VERSIONINFO<\/strong> version number.<\/p>\n\n\n\n

What to do ?<\/p>\n\n\n\n

Option #1: Ignore the Label ?<\/h4>\n\n\n\n

Could we simply ignore the alpha<\/code> label in the pre-release identifier, retain only the build number (the .15<\/code> part of the identifier) and use this for the Build<\/code> of the VERSIONFINO<\/strong> ? This would mean that our pre-release VERSIONINFO<\/strong> for 0.1.0-alpha.15<\/code>would be:<\/p>\n\n\n\n

0.1.0.15<\/code><\/p>\n\n\n\n

The problem with this is that once the 0.1.0<\/code> is released, that pre-release identifier is dropped. For Semantic Versioning<\/strong> this is handled by the rules of precedence which state that a version with an identifier has lower precedence<\/em> than the same version with no<\/em> identifiers.<\/p>\n\n\n\n

That is, 0.1.0<\/code> is a more current <\/em>version than 0.1.0-alpha.15<\/code>. This is fine as the pre-release label clearly identifies it as such. The alpha.15<\/code> build of 0.1.0<\/code> is not yet the released version of 0.1.0<\/code>. This makes perfect sense.<\/p>\n\n\n\n

But applying the same reasoning to a label-less VERSIONINFO<\/strong> equivalent leads to the clearly counter-intuitive outcome that 0.1.0<\/code> is a more current<\/em> version than 0.1.0.15<\/code>!<\/p>\n\n\n\n

Option #2: Subvert Expectations<\/h4>\n\n\n\n

This isn’t so much a second option as a way of lending legitimacy to the first (or trying to).<\/p>\n\n\n\n

If 0.1.0-beta.15<\/code> is a pre-release version then we could take the position that it is a pre-release not of 0.1.0<\/code> but of some later, future version as yet to be decided. That is, the next release version might be 0.1.1<\/code> and so 0.1.0.15<\/code> is a valid earlier<\/em> version, identified as a pre-release by the non-zero Build<\/code> field. All release versions would have a Build<\/code> of 0<\/code>. Any version with a non-zero Build<\/code> number is a pre-release of some future version.<\/p>\n\n\n\n

This has some obvious drawbacks, not least of which is the fact that there is no way to tell from 0.1.0.15<\/code> alone which subsequent version it is a pre-release version of. It might be 0.1.1<\/code> or 0.2.0<\/code> or even 1.0.0<\/code> etc.<\/p>\n\n\n\n

No, that’s not going to fly.<\/p>\n\n\n\n

Option #3: Use StringFileInfo for Semantic Version<\/h4>\n\n\n\n

Anyone intimately familiar with the VERSIONINFO<\/strong> resource will have noticed that I have so far not mentioned the FileVersion<\/em> and ProductVersion<\/em> values held in the StringFileInfo<\/strong> block, maintained in addition to the FILEVERSION<\/em> and PRODUCTVERSION<\/em> numeric fields. <\/p>\n\n\n\n

These are simple string values (promising!<\/em>) and the Microsoft documentation<\/a> clearly states (with an example provided of “5.00.RC2”) that both of these can hold any arbitrary string! Unfortunately, when examining the version properties of a file in Windows Explorer<\/strong>, either the Windows Explorer<\/strong> dialog is using the FILEVERSION<\/em> value in preference over the FileVersion<\/em> string, or the FILEVERSION<\/em> value actually ignores any non-numeric content that you try to put in this field.<\/p>\n\n\n\n

I really should check which it is, just to be sure, but the fact remains that what people will see when they inspect the Details<\/strong> of the file in Windows Explorer<\/strong> is not particularly helpful in this case.<\/p>\n\n\n\n

That is, a subtle attempt to reformat the version into a format ‘compatible’ with the 4-dotted fields expected in a VERSIONINFO<\/strong>, e.g:<\/p>\n\n\n\n

VALUE "FileVersion", "0.1.0.beta-15"<\/code><\/p>\n\n\n\n

Results in an actual File Version<\/em> value of… 0.1.0.15<\/code> being displayed. <\/p>\n\n\n\n

The good news is that the ProductVersion<\/em> property does<\/em> display any arbitrary string provided.<\/p>\n\n\n\n

This led me to the approach I eventually adopted. <\/p>\n\n\n\n

\n\n\n\n

In short, I decided that Semantic Versioning<\/strong> would be retained and maintained in the ProductVersion<\/em> string but not FileVersion<\/em>. I still needed (or rather, ‘wanted’) a unique, incrementing version that I could use in the other version fields that would not be confusing.<\/p>\n\n\n\n

Remember that the ‘build number’ derived from the GitVersion<\/strong> applies only to pre-release<\/em> builds which presents two problems with using that.<\/p>\n\n\n\n

  1. It will reset when the major<\/em>, minor<\/em> or patch<\/em> numbers are incremented<\/li>
  2. It does not get derived at all<\/em> for release<\/em> builds<\/li><\/ol>\n\n\n\n

    What I wanted was a constantly increasing number that would be reliably and consistently generated regardless of the branch on which the build was being performed (be it a pre-release build or master<\/em> release build).<\/p>\n\n\n\n

    However, assuming that this value would be used in either the Revision<\/code> or Build<\/code> fields of the VERSIONINFO<\/strong> it also could not exceed the value 65534.<\/p>\n\n\n\n

    I eventually settled on using not one but two<\/em><\/strong> such numbers.<\/p>\n\n\n\n

    Since only the Major<\/code> and Minor<\/code> fields are strictly in ‘common’ between Semantic Version<\/strong> and VERSIONINFO<\/strong> I decided that these would also be the only values carried forward<\/em> from the Semantic Version<\/strong> into the VERSIONINFO<\/strong>. I would derive the Revision<\/code> and Build<\/code> values independently<\/em> of the Major<\/code> and Minor<\/code> version. using a constantly incrementing scheme.<\/p>\n\n\n\n

    There are numerous solutions to the constantly incrementing build number problem for Azure DevOps<\/strong>. The approach I decided to use is derived from a value that increases intrinsically and inevitably over time: Time itself<\/em>.<\/p>\n\n\n\n

    For Revision<\/code> I would use a days<\/em> counter. That is, this field will identify the date<\/em> on which the build was produced, calculated as the number of days since 1st Jan 2000<\/em>. Why that date ? Why not ? \ud83d\ude42<\/p>\n\n\n\n

    For Build<\/code> I would use a second<\/em> counter. That is, this field identifies the time of day<\/em> at which the build was produced. But since there are 86400 seconds in a day, this number is actually divided by 2 in order to remain within the 65534 limit of the field.<\/p>\n\n\n\n

    This gives me a ‘resolution’ for my builds of only 2 seconds, but I don’t anticipate ever having a problem caused by my builds completing in under 2 seconds! The days calculation gives me ~160 years in which to figure out a solution to the problem of that number ‘running out’, which should be enough time I think.<\/p>\n\n\n\n

    \n\n\n\n

    Now all that remains is to get this into my build pipeline. Bearing in mind that I am using the command line compiler in my builds, the trick of referencing a .rc<\/code> file and having the compiler automatically invoke the resource compiler to produce a .res<\/code> file won’t work. Even if it did, the header files necessary for compiling a VERSIONINFO<\/strong> resource are not provided with Delphi<\/strong>.<\/p>\n\n\n\n

    Fortunately my self-hosted build machine already has a Windows 10 SDK<\/strong> installed, so I can use the resource compiler from that directly.<\/p>\n\n\n\n

    In my project .dpr<\/code> I reference a versioninfo.res<\/code>file. A version of this file is maintained in the repository with properties that identify any build as a “Development” version.<\/p>\n\n\n\n

    This isn’t perfect. Ideally it would at least also identify the build as a development build of the Major<\/code> and Minor<\/code> version from the GitVersion.yml<\/code> configuration. This is something I may turn my attention to at some point, if it becomes a problem. But until then there are bigger fish to fry.<\/p>\n\n\n\n

    Alongside the versioninfo.res<\/code> file is a versioninfo.rc<\/code> file. This is the VERSIONINFO<\/strong> resource script containing most<\/em> of the meta-data needed for the version info itself:<\/p>\n\n\n\n

    \/\/\n\/\/ Include the necessary resources\n\/\/\n#include <winver.h>\n#include <versioninfo.h>\n\n#define VER_FILENAME     "duget.exe"\n#define VER_PRODUCTNAME  "Duget Package Manager for Delphi"\n#define VER_INTERNALNAME "Duget CLI"\n#define VER_COMPANYNAME  "Deltics (Jolyon Direnko-Smith)"\n#define VER_COMMENTS     "For more information visit https:\/\/duget.org"\n#define VER_DESCRIPTION  "Duget CLI Client Executable"\n#define VER_COPYRIGHT    "(c)2019 Jolyon Direnko-Smith"\n\n#ifdef RC_INVOKED\n\tVS_VERSION_INFO VERSIONINFO\n\tFILEVERSION             VER_MAJOR,VER_MINOR,VER_TIMESTAMP_DAYS,VER_TIMESTAMP_SECONDS\n\tPRODUCTVERSION          VER_MAJOR,VER_MINOR,0,0\n\tFILEFLAGSMASK           VS_FFI_FILEFLAGSMASK\n\tFILEFLAGS               0\n\tFILEOS                  VOS_NT\n\tFILETYPE                VFT_APP\n\tFILESUBTYPE             0\n\tBEGIN\n\t\tBLOCK "StringFileInfo"\n\t\tBEGIN\n\t\t\tBLOCK "040904B0"\n\t        BEGIN\n\t\t\tVALUE "Comments",         VER_COMMENTS\n\t\t\tVALUE "CompanyName",      VER_COMPANYNAME\n\t\t\tVALUE "FileDescription",  VER_DESCRIPTION\n\t\t\tVALUE "FileVersion",      VER_FILEVERSION\n\t\t\tVALUE "InternalName",     VER_INTERNALNAME\n\t\t\tVALUE "LegalCopyright",   VER_COPYRIGHT\n\t\t\tVALUE "OriginalFilename", VER_FILENAME\n\t\t\tVALUE "ProductName",      VER_PRODUCTNAME\n\t\t\tVALUE "ProductVersion",\t  VER_PRODUCTVERSION\n\t\t\tEND\n\t\tEND\n\t\tBLOCK "VarFileInfo"\n\t\tBEGIN\n\t\t\tVALUE "Translation", 0x0409,1200\n\t\tEND\n\tEND\n#endif<\/code><\/pre>\n\n\n\n
    Some key information is missing however, and this is expected to be provided in the versioninfo.h<\/code> file that is #included<\/code> at the top of the file.  This file is created at build time by the build pipeline:<\/p>\n\n\n\n
    steps:\n- template: gitversion.yml@templates\n\n- powershell: |\n    $baseDate = [datetime]"01\/01\/2000"\n    $baseTime = [datetime]"00:00:00"\n    $now = Get-Date\n\n    $daysInterval = New-TimeSpan -Start $baseDate -End $now\n    $secsInterval = New-TimeSpan -Start $baseTime -End $now\n    $days = $daysInterval.Days\n    $secs = [int]($secsInterval.TotalSeconds \/ 2)\n\n    $verMajor = $ENV:GitVersionMajor\n    $verMinor = $ENV:GitVersionMinor\n    $gitVersion = $ENV:GitVersion\n\n    Remove-Item versioninfo.h | Out-Null\n    New-Item versioninfo.h -ItemType file | Out-Null\n    Add-Content versioninfo.h "#define VER_MAJOR $verMajor"\n    Add-Content versioninfo.h "#define VER_MINOR $verMinor"\n    Add-Content versioninfo.h "#define VER_TIMESTAMP_DAYS    $days"\n    Add-Content versioninfo.h "#define VER_TIMESTAMP_SECONDS $secs"\n    Add-Content versioninfo.h "#define VER_FILEVERSION    ""$verMajor.$verMinor.$days.$secs"""\n    Add-Content versioninfo.h "#define VER_PRODUCTVERSION ""$gitVersion"""\n    type versioninfo.h\n\n    $ENV:Path += ';c:\\Program Files (x86)\\Windows Kits\\10\\bin\\10.0.17134.0\\x86'\n    $include  = 'c:\\program files (x86)\\Windows Kits\\10\\Include\\10.0.17134.0\\um;'\n    $include += 'c:\\program files (x86)\\Windows Kits\\10\\Include\\10.0.17134.0\\shared'\n\n    $cmd = 'rc -i"' + $include + '" versioninfo.rc'\n    Write-Host ":>" + $cmd\n    Invoke-Expression $cmd\n  displayName: Calculate and Update VersionInfo<\/code><\/pre>\n\n\n\n
    The pipeline first performs the GitVersion<\/strong> templated task to derive the necessary version information from the GitVersion<\/strong> configuration and commit history.<\/p>\n\n\n\n
    This has been updated recently to yield more information now than just<\/em> the semantic version.  Component values of that version information are now also set in environment variables which we can see the subsequent PowerShell<\/strong> script then uses to construct the content of the versioninfo.h<\/code> header file.<\/p>\n\n\n\n
    This versioninfo.h<\/code> file is first deleted (a development version is present in the repo so we can be certain that it will exist and need to be deleted as part of a build).  Once the header file has been created as required, we emit it to the console to help identify and problems in the process when reviewing the build logs.<\/p>\n\n\n\n
    There is then a bit of minor house-keeping needed to prepare for the invocation of the Windows SDK <\/strong>resource compiler which produces the versioninfo.res<\/code> file referenced in the project itself.<\/p>\n\n\n\n
    Once successfully compiled, the startup code of the duget<\/strong> executable is then able to extract it’s own version info.  When duget<\/strong> commands are performed this startup code identifies duget<\/strong> in the console with output similar to:<\/p>\n\n\n\n
    Duget Package Manager 0.1.0-alpha.15\nBuild 0.1.7217.23479 (For more information visit https:\/\/duget.org)\n(c)2019 Jolyon Direnko-Smith<\/pre>\n\n\n\n
    Internally, the ProductVersion<\/em> string<\/em> provides the semantic, human meaningful version of the product whilst the PRODUCTVERSION<\/em> identifies the Major.Minor<\/code> version of the product without any Revision.Build<\/code> info (both zeroed since they are not relevant to the product<\/em> version).<\/p>\n\n\n\n
    The FILEVERSION<\/em> and FileVersion<\/em> string<\/em> values both<\/strong> identify the detailed build version complete with date and time of the specific build that produced this exe<\/em>.<\/p>\n\n\n\n
    \n\n\n\n
    How do you manage version info in your automated builds ?  What do you think of this approach ?<\/p>\n","protected":false},"excerpt":{"rendered":"
    [Estimated Reading Time: <\/span> 8<\/span> minutes]<\/span><\/span> How to make Semantic Version make sense in a VERSIONINFO world without Semantic Versioning.<\/p>\n","protected":false},"author":2,"featured_media":3005,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"jetpack_publicize_message":"VERSIONINFO and Semantic Versioning - Squaring that particular circle needn't be difficult.","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":[]},"categories":[324,322,323,4,321,346],"tags":[342,327,329,344,347,343],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/bart-simpson-generator-1.png?fit=1024%2C343&ssl=1","jetpack_shortlink":"https:\/\/wp.me\/p1TKYv-Mo","jetpack_sharing_enabled":true,"jetpack-related-posts":[{"id":2985,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2985\/","url_meta":{"origin":3000,"position":0},"title":"Duget – RESTORE, UPDATE and What’s Next ?","date":"26 Sep 2019","format":false,"excerpt":"Wrapping up this short series on duget, discussing RESTORE and UPDATE, arguably most important and useful commands in the duget repertoire.","rel":"","context":"In "automation"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/duget-warriors.png?fit=929%2C256&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":2979,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2979\/","url_meta":{"origin":3000,"position":1},"title":"Duget Package Manager for Delphi","date":"24 Sep 2019","format":false,"excerpt":"An overview of the the duget package manager, outlining the current state of this project and the first in a quick-fire series to explore the key features.","rel":"","context":"In "automation"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/duget-warriors.png?fit=929%2C256&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":2983,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2983\/","url_meta":{"origin":3000,"position":2},"title":"Duget – PUSH-ing Packages","date":"25 Sep 2019","format":false,"excerpt":"We now know a little more about this duget thing, and have seen how to create a package. But a package cannot be consumed 'in situ' - it must be made available via a feed. Which brings us to the PUSH command.NOTE: Don\u2019t worry, I have my priorities straight. This\u2026","rel":"","context":"In "automation"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/duget-warriors.png?fit=929%2C256&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":2936,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2936\/","url_meta":{"origin":3000,"position":3},"title":"Azure DevOps – Iterative Insertion Fixed!","date":"19 Sep 2019","format":false,"excerpt":"I figured out the iterative insertion problem and my build pipeline is now TIGHT! Fixing it was super-easy in fact, barely an inconvenience.","rel":"","context":"In "automation"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/pipelines-hero-code-1024x256.jpg?fit=1024%2C256&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":2919,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2919\/","url_meta":{"origin":3000,"position":4},"title":"Azure DevOps – Now You Too Can Use My Template(s)","date":"14 Sep 2019","format":false,"excerpt":"Learn how you too can use my Delphi build template in your own Azure DevOps pipelines, and a sneak preview of something special coming soon...","rel":"","context":"In "automation"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/github-512.png?fit=512%2C512&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":2931,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2931\/","url_meta":{"origin":3000,"position":5},"title":"‘Sorry, this script is too long…’","date":"18 Sep 2019","format":false,"excerpt":"An object lesson on the importance of defensive programming and providing helpful error messages to your users.","rel":"","context":"In "Azure DevOps"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/Mark_Twain_life_1900s.jpg?fit=883%2C331&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]}],"_links":{"self":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/3000"}],"collection":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/comments?post=3000"}],"version-history":[{"count":4,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/3000\/revisions"}],"predecessor-version":[{"id":3015,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/3000\/revisions\/3015"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/media\/3005"}],"wp:attachment":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/media?parent=3000"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/categories?post=3000"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/tags?post=3000"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}