Jive PS Versioning Guidelines

Version 1

    This document will describe the versioning guidelines utilized by Jive Professional Services, which should serve as a best practices model for customers and partners operating within the confines of Jive's SVN/JIRA environment.

     

    TL/DR

    The versioning system that Jive PS uses naming conventions that reflect the customer's current SOW (Statement of Work) number, along with the pending production release, and the current UAT release.  This, of course, means that each new push to a customer's UAT environment gets a new version number.  The following is an example of a working Jive PS version number:

     

    versions.png

     

    In short, the version displayed above refers to the 4th UAT (-d4) release for a follow-on production release (.1) addressing SOW #2 (2) for a customer.

     

    Going Deeper

     

    The SOW

    The first time Jive PS engages with a customer, a SOW is drawn up, which is referred to as SOW #1.  Any customization that comes out of that engagement is referred to as 1.x.  All subsequent statements of work increment that number.  The version numbers for the next SOW's production release(s) would be 2.x.

     

    The Production Release

    Each SOW may involve one or more releases of custom code to production.  Ideally there is only one, but bug fixes and change orders often necessitate one or more follow-on pushes to production after initial launch.  These production release are denoted in the second part of the version nomenclature, in a zero-based fashion.  For example, the first release to production for SOW number 2 would be 2.0.  The next release to production, under the guise of the same SOW, whether because of a change order or bug-fix release, would be 2.1.  Then 2.2 and 2.3, and so on.

     

    The UAT Release

    Each push to UAT is potentially a production release, and needs to be versioned.  However, just adding a .x to the end of the production release (2.1.4) is cause for confusion, since the additional number indicates that the release is a revision on a prior release, which is not the case.  Since we want to make it clear that each UAT release is a "release candidate" or sorts, or that it is in development, we add the -dx suffix to the production release, in a one-based fashion.  So, continuing on our previous example, our first push to UAT for the upcoming 2.1 production release would be 2.1-d1.  The next would be 2.1-d2, and so on.