Currently we are in process of migrating to new less confusing terminology. Gradually we are going to replace old terminology we used for older AppBase versions with the new.
This articles explains the terminology we are using now in connection to the terminology we used before.
The Terminology explained
Version
Full term is "Product Version", do not confuse with "Build Version". "Product Version" is Major.Minor version of the AppBase product with a usual lifecycle one Product Version release annually. Currently we have created product versions "5.2","5.6","6.0","6.5","6.6".
Product Version "6.7" is in development now. Product Version may have several releases as explained further
Release
This is a stand alone AppBase release which we usually announce via emails and articles in the Announcements section. Release of the product starts with the first release in the "Product Version" line. The consequent releases usually have all previously released fixes to the previous version and may have new features added. By our design we trying to make all consequent releases for the same "Product Version" to have as few breaking changes as possible.
This is better demonstrated with this example. In 2018 we have been working on AppBase Product version 6.5. We started that work by releasing the first release (aka "6.5 GA"). During our further work we have implemented some fixes and new features and made the second release (aka "6.5 GA SP1"). After the second release we have made the third release (aka "6.5 SP1 Update 1") and concluded our work on Product version 6.5 with the forth release (aka "6.5 SP1 Update 2").
Then we started year 2019 with work on the next Product Version 6.6. We made the first release (aka "6.6 GA") by the end of year 2018 and continuing year 2019 on improving Product Version 6.6 while also working on the next Product Version 6.7 (scheduled to be released at then end of year 2019). We plan to make several releases for AppBase Product Version 6.6 during year 2019 - as was previously said - those releases will have fixes made to the previous release (aka "6.6 GA") as well as some new features that do not have any significant breaking changes.
To simplify our naming conventions we have decided to give all release names that have both Product Version and the release number preceding by letter R (short from Release). Example: "6.5 GA R1"
After the product version we use abbreviation GA to indicate that the release is Globally Available (public release). We reserve right to add more abbreviation if needed in the future (for now only possible abbreviation that comes in mind is Preview Build - PB to indicate the release we make ahead of schedule with less testing or support - but this is not fixed in stone)
The table below explains how we call our previous releases with connection to how we used to call them.
| Old Name | New Name |
|---|---|
| 6.5 GA | 6.5 GA R1 |
| 6.5 GA SP1 | 6.5 GA R2 |
| 6.5 GA SP1 Update 1 | 6.5 GA R3 |
| 6.5 GA SP1 Update 2 | 6.5 GA R4 |
| 6.6 GA | 6.6 GA R1 |
For us, the table above looks as simplified and improved terminology compared to the what we used before.
We think this terminology removes some confusion when we called some of our releases as Service Pack or Service Pack Update 1 etc. The confusion comes from some other popular products releasing "Service Packs" as updates, not as a standalone installation package. Some of them go as far as calling "Service Pack" a cumulative update. Term "Update" is also widely used as a package with some changes (fixes, features etc) - not as standalone product release. We would like to adopt those terms in our naming conventions, therefore we stopped calling releases as "Service Pack" or "Update"
Update
"Update" is a generally available package with changes. The changes may be of any nature: fixes, new features, security improvements etc. The package usually contains a set of resources (dll,aspx pages etc) with instruction how to apply the update. Recently we started to use same approach to install the updates as we do with the standalone releases - we instruct you to apply the update on your "_Instlocalcache" directory and then execute "Server-Install".
The main difference between "Update" and "Release" is that the former is a package that can be installed only on top of existing installation when the latter can be installed as a new installation too. Also "Release" indicates a significant milestone in the Product lifecycle and may bring some additional procedures that "Update" usually does not have (like more pronounced public announcement, migration plans from previous releases to the new etc). And of course "Release" usually brings more changes than an "Update".
We used to call these update packages as "patch" but that also brought confusion because "patch" usually means "a small piece of code which can be added to a computer program to improve it or correct a fault". Historically we used term "patch" for small private (customer specific) bugfixes released to particular clients and we wish to continue doing so, while using term "Update" for public "patches"
While the naming convention we decided to use does not require it is flexible enough to have both, we have decided that at the moment all our consequent updates are cumulative.
This means that Update 3 for release version "6.5 GA R3" will include both "Update 1" and "Update 2" in addition to the features of the "Update 3" itself.
We can use sequential numbers thanks to our decision for all updates to be cumulative, if in the future we will decide to change that or if we will decide to release a non-cumulative update for any reason we than may decide to use a different name for such update, for example "U1901310" or something like that - this is not yet decided.
Usually an "Update" undergoes the shorter version of our manual QA testing procedures - meaning that we install the basic version, then apply the update and then have our QA team test only the feature that were changed in such update.
Patch
Historically we used term "Patch" for the packages with changes that were prepared for a specific customer. Usually such patches could not be applied to another customer installations dues to specific pre-requisites or the patches nature.
While we do not plan to create many such "private" patches in the future, this is still possible. We would like to continue using this term "Patch" for such private patches only.
Usually such patches do not undergo the QA testing procedure and tested instead by developer preparing the patch. However depending on situation anything is possible even full QA testing procedure that we usually apply to the releases.