Note: this is a working document and may be updated/altered without warning.

Assumptions:
 

This document will not cover the incremental nature of semantic versioning in detail. Instead, before proceeding, you should have an understanding on how Semantic Versioning works.  A reference guide can be found here: Semantic Versioning 2.0.0

Projects:

We identify different applications need for semantic versioning based on their use.  Currently there are four typical use-cases defined:

1.   Internal Dependencies

These include dependencies that are developed and managed for internal use only, they are not standalone applications.  There is not a defined release cadence. These include the following projects:

• at-fullcount-model
• at-maven-plugins
• at-payment-processing
• at-test-helper
• authentication
• fullcount-admin-model
• integration-model
• notifications
   

SemVer usage:  These will be updated to use semantic versioning.  When updating one of these projects one should also consider if the updates should be propogated to dependent projects.

2.   Web Applications / Stand alones

These include our customer and internal web based applicaitons.  Generally these follow a monthly release cadence. They do not include functionallity available via external integrations (apis).  These include the following projects:

• backoffice
• at-fullcount-touchscreen (POSWebApplication)
• at-selfservice-portal
• device-management
• mobile

SemVer usage:  These will be determined on an individual basis. They generally follow a defined release cadence, and currently don't use SemVer. Because they are not externally available they are less likely to need strict enforcement of SemVer. They are dependent on many of our other internal projects, and will require review prior to release to determine if any of thier own dependencies should be updated.

3.   Web API's 

These include both internal and external available API's via web interfaces.  This means that we likely have internal (and external) systems that depend on the API's within; however we cannot enforce/ensure this with semantic versioning in the same way we can with maven depencies.

• integration-vision
• integration-pcc
• event-logger (deployment-web-service)
• at-remote-connections
• client-access

SemVer usage:  These will be changed to enforce SemVer.

4.   Internally Isolated Projects

These are projects that are used only internally, and have no projects that are dependent upon them.

• backoffice-ui-test
• device-management-ui-test
• deployment-tool
• at-uptime

SemVer usage:  These currently don't have any need to implement SemVer themselves as they do not have any artifact, however thier listed dependencies WILL need updated to reflect other internal dependency updates.

Process

During the development cycle, the Maven <version> tag should be appended with '-SNAPSHOT'. this will indicate that it is a development cycle build and should not be used in production environments. (ex. 2.10.8-SNAPSHOT' :   Major=2, Minor=10, Patch=8, -SNAPSHOT indicates non-release build.)  These will be put in our 'SNAPSHOT' artifact repository on Archiva.

Once a release candidate is identified, you should ensure the Semantic Version is correct,  or if any Major Minor or Patch values should be updated. Once that is completed, and the version updated accordingly, the '-SNAPSHOT' should be removed; the pom committed; and an automatic build completed.  Artifacts what do not include '-SNAPSHOT' will be placed in the 'Release' Repository on Archiva.

After the automatic build is complete, you should increment the version to Major.Minor.<Patch+1>-SNAPSHOT.  This will indicate that all development for the previous release has stopped, and any changes will be at minimum a Patch release. (ex: 2.10.8  ->  2.10.9-SNAPSHOT)