Version your software

How you version your software from the start can make life allot easier for you as you grow.
Creating support branches so long term version can be supported means that all customers do not need to upgrade as soon as it is available. This allows for testing in a few live environments before being rolled out to all.

This is just a guide and should be changed to match the requirements of your project

Tag definitions

Semantic versioning on all code released.
MAJOR.MINOR.PATCH
1.10.25

You could also add one more section as pre-release.
i.e. 1.10.25.3

Support definitions

If you mark releases with what level of support is available then clients will know what to expect and not drag their feet with their next upgrade.

LTS
Long Term Support: These releases will be supported for up to x years.
Bugs will fixed. No new features will be added once the release is marked as LTS.
LTS tags will be multiples of 10 minors: 1.x0.x
i.e. 1.10.0, 1.20.0

GA
Generally Available: These releases will be support for up to x months.
Bugs will be fixed. No new features will be added once the release is marked as GA
GA tags will be multiples of 10 minors (5 indented): 1.x5.x
i.e. 1.15.0, 1.25.0

EAP
Early Access Program: These releases will not be supported.
Releases are for progress review only on non-live environments.
i.e. 1.82.0, 1.97.0

Website definitions

Live
GA and LTS releases will be made available here.
Requested tag version to be approved from UAT environment before upgrade can be made live.

UAT – User Acceptance Testing
GA and LTS releases will be made available here.

Test
EAP releases will be made available here.
There is likely to be more bugs in these versions so bug tickets should be limited in these versions.

Agile Process

Sprint process is over a x week period.
Add further details here to match your process.

 

These are the main areas I like to define when providing software to multiple clients.

Leave a Reply

Your email address will not be published. Required fields are marked *