Release Process and Release Schedule
The objective of this document is to provide an overview of the process the Bullhorn for Salesforce team follows to ensure that all customers are informed of the latest releases and have prompt access to the most up-to-date version of the product.
release process and scheduling has these goals:
- Adhere to a regular release schedule to keep customers software up to date
- Release new code and functionality frequently in small, safe and incremental steps
- Have predictability in releases and output
product will have 12 releases per year consisting of:
● 3 major releases (GA)
● 3 minor releases between each major release
Release Policy
The goal of our release policy is to give our customers the latest software on a regular basis but with options that allow for some flexibility.
- We release a major version of our software every 4 months (3 times a year). All customers should be upgraded to major versions, or GA (Generally Available) releases.
- Customers can opt-in to get the minor releases. A list is maintained of customers that automatically get the minor releases.
- Customers that have opted in will automatically get the new minor releases. Bullhorn installs the new releases automatically on a time frame determined by Bullhorn.
- Customers can also get a minor release as a once-off event, if needed, for example when a customer needs a specific bug fix or feature.
- Customers that are on the major release schedule must choose if they want Bullhorn to install the new versions or not. If they do, Bullhorn installs the new releases automatically on a time frame determined by Bullhorn. Customers can also choose to install new versions themselves.
- For customers that choose to install the major releases themselves, Bullhorn limits the time for which the previous major version is supported. Customers have 6 weeks to install the new version themselves. After this 6-week period, Bullhorn will automatically install the new version.
Patches
Patches are not the preferred mechanism for delivering fixes to existing functionality. Under no circumstances do patches include NEW functionality. Under extenuating circumstances, patches may be released in these scenarios:
- A bug is reported which impacts one or more customers as it causes the application to be unavailable or significantly impacts daily work.
- A bug is reported by a large customer (>200 seats) which is severe and critical, and the customer is unable to upgrade to a new package.
- Some large customers need to go through substantial testing before installing a new package and can't easily upgrade to a new version on short notice. Therefore, in exceptional circumstances we can fix a bug with a patch on an older release.
Patches can only support small fixes. There are multiple technical limitations which are listed in the Patch Restriction section.
Patches are only made for the three most recent releases. If we are on the 3rd minor release in a cycle we will patch back 4 releases, to include the latest major release.
Patches are not part of the regression test cycle and therefore the impact on other parts of the application is not verified.
Bullhorn Technical Product Managers (TPMs) will decide if a patch is distributed to a selection of customers or all customers depending on the severity.
Release schedule
Releases are planned in advance. The dates communicated are target dates and are subject to change, although Bullhorn will make every effort to comply with the schedule.
| Releases | Release reference | Start date sprint | Code freeze |
Release date + deployment |
|---|---|---|---|---|
| January | 2019.1 | Dec.10th | Jan. 11th | Jan. 25th |
| February | 2019.2 | Jan.14th | Feb.8th | Feb.22th |
| March | 2019.3 | Feb.11th | March 8th | March 22nd |
| April | 2019.4 | March 11th | April 5th | April 19th |
| May | 2019.5 | April 8th | May 3rd | May 17th |
| June | 2019.6 | May 6th | June 3rd | June 14th |
| July | 2019.7 | June 3rd | June 28th | July 12th |
| August | 2019.8 | July 1st | July 26th | Aug. 9th |
| September | 2019.9 | July 29th | Aug. 23rd | Sept. 6th |
| October | 2019.10 | Aug.26th | Sept.20th | Oct.4th |
| November | 2019.11 | Sept.23rd | Nov.1st | Nov.15th |
| December | 2019.12 | Nov.4th | Nov. 29th | Dec.13th |
Patch Restrictions
Developments in a patch development org is restricted.
- You can’t add package components.
- You can’t delete existing package components.
- API
API, or Application Programming Interface, is used by customers to create custom career portals or to take advantage of Data Mirror/DataMart. Bullhorn prefers to use REST API. and dynamic Apex access controls can’t change for the package. - No deprecation of any Apex code.
- You can’t add new Apex class relationships, such as extends.
- You can’t add Apex access modifiers, such as virtual or global.
- You can’t add new web services.
- You can’t add feature dependencies.