Table of Contents

Versioning

This tutorial will teach you the basics of versioning for your services.

Prerequisites

  1. Windows 10/11
  2. Visual studio 2019/2022
  3. Phoesion Glow Blaze , with Reactor running (see getting started guide)

Sample Code

You can download the Sample Code archive from the downloads section.
This tutorial follows the 4_Versioning sample in the archive. (View code on GitHub)

Introduction

The Phoesion Glow system provides a versioning mechanism, that allows you to easily develop,manage and target multiple versions of your services/api running concurrently. Each Service and each Module can have it's own independent version.

Module Versioning

Versioned module Namespace/Class

Each Module can have it's own unique version number. The Phoesion Glow system can understand the version of each module by it's class name.

For example, as seen in Foompany.Services.SampleService1 project from the 4_Versioning sample, when versioning a module from a class name of a module you change it to :
Module_Versions

With class names and namespace :
Module_Versions_Class

Targeting module versions

Using the SampleService1 service in the sample, you can access the modules as so :

  • http://host/SampleService1/SampleModule1/Action1
    By default, with NO version specified in the url, the latest version (highest version number) available will be used. In this case v2.

  • http://host/SampleService1/SampleModule1/v1/Action1
    With a specified version in the url, the v1 version of the module will be hit.

  • http://host/SampleService1/SampleModule1/v2/Action1
    With a specified version in the url, the v2 version of the module will be hit.

  • http://host/SampleService1/SampleModule1/v0/Action1
    The special version number v0 specifies the latest version will be used. (the same as if no versioning information was specified).

Summary

Having many class versions under the Module namespace, allows you to preserve a strong-typed and SOLID implementation of your versions. Each module version class can the have it's own api module with it's version-specific api prototypes. You can also inherit from older versions and only change or override specific parts of the module's logic.

Service Versioning

Each Service can have it's own unique version number. The Phoesion Glow system can understand the version of each service by the assembly name version suffix.

For example, as seen in Foompany.Services.SampleService2 projects from the 4_Versioning sample, when versioning a service you can create a new project with the version as a suffix :
Service_Versions

Note

You need to add the new project to your Phoesion Glow Project services, like you would for a new service

Targeting service versions

Using the SampleService2 service in the sample, you can access it as so :

  • http://host/SampleService2/SampleModule1/Action1
    By default, with NO version specified in the url, the latest version (highest version number) available will be used. In this case v2.

  • http://host/SampleService2/v1/SampleModule1/Action1
    With a specified version in the url, the v1 version of the service will be hit.

  • http://host/SampleService2/v2/SampleModule1/Action1
    With a specified version in the url, the v2 version of the service will be hit.

  • http://host/SampleService2/v0/SampleModule1/Action1
    The special version number v0 specifies the latest version will be used. (the same as if no versioning information was specified).

Summary

Having different projects for each service version, allows you to preserve a strong-typed and SOLID implementation of your versions. The separation of projects/assemblies decouples the dependencies/references of older versions and each version can run in a separate process/container like if it was a completely different service. You can also reference and inherit parts of the older service versions if needed.