Time Allocation
In Core, there are two major releases (May and November) and two minor releases (February and August) each year. Major and minor releases are release versioning types given to categorize the stages throughout the development process. As you can see the table below, there are slight differences between them. Patches and hotfixes are another type of release, but these do not require partners to migration. So we won't focus too much on those here.
Change | Major Release | Minor Release |
Interface changes | ✔ | ✖ |
Requires migration | ✔ | Optional* |
Requires testing by partners | ✔ | Optional* |
Reconstruction and Improvements | ✔ | Typically none* |
Feature changes | ✔ | Typically none* |
Optional * - Partners have the option to migrate |
Differences and similarities between major and minor release.
Both minor and major releases are recommended to start migrating 7 weeks before the release which is when Core reaches code freeze. And the migration process should be completed 2 weeks after the code freeze. Then the testing should be done on the RC (Release Candidate) which should be available 4 weeks before the release. And the testing should be completed at least 2 weeks before the release.
Simple migration timeline from code freeze until the release for both major and minor release.
It is recommended to go through a migration test and smoke test once the migration has been performed. The full regression is done only after the smoke test to smooth out the testing process. Although migration is optional for a minor release, it is still recommended to go through the test. Therefore, smoke tests are highly recommended to be done for both major and minor releases.
Resources
When the time comes for migration, you will see a post on the briefcase on the MyConfigura page like below:
It will usually provide a link to the Migration Guide as well as webinars that you can attend where you can see the upcoming new or changed features in the new release. If you're interested in knowing what the webinar looks like, you can take a look here: Migration to 11.5. It is advised to make sure to read the guide first before going to webinars so you can understand the context first.
Process
There are 7 simple steps to go through migration:
Step 1: Git Branch Select
Switch your git base repository. During the migration process version/xx.x/beta should be used (i.e. version/11.5/beta). The branch contains code for the next major or minor release once it becomes available publicly in the beta box under Core Distribution in Build Center on the MyConfigura page (How to Publish). On a side note, when you want to see the latest code release, then the release branch will be in version/xx.x/official (i.e. version/11.5/official).
Git branch for base repository: switching branch to version/11.5/beta.
Step 2: Code change
Make your code changes in your Extension by looking at the Migration Guide and fix all your compilation and runtime errors. For example, when migrating from version 11.0 to version 11.5, a new class called AODataPanelJunctionSnapper
was implemented in Abstract Office. So in Fika Extension, FODataPanelJunctionSnapper
class was changed as shown below:
Shows a section of changes made in Abstract Office in Migration Guide from 11.0 to 11.5.
// Old public class FODataPanelJunctionSnapper extends PanelJunctionSnapper {
// New (version 11.5) public class FODataPanelJunctionSnapper extends AODataPanelJunctionSnapper {
Change made in code, under cm.custom.fika.office.dataFika, to adjust to version 11.5.
Step 3: Git Push
After making your changes on Emacs, you need to push your local branch, so you can create a Merge Request, so eventually, your work will get merged for the upcoming build.
Step 4: Build
Create a new build by using Build Central in CET Operator.
Release the new build under Build Center on the MyConfigura page.
Step 5: Testing
QA goes through testing using QA Migration Testing Guides.
Step 6: Sign off Process
After your Extension has been tested, the QA or the person in charge of the release can navigate to Projects > Manufacturer > [Manufacturer Name] > QA on MyConfigura and verify that the latest build has been tested and then sign off. The sign off is done once for that particular version that was tested.
Step 7: Release
Once your release is ready to go, you can drop it in the Official Distribution. And you are all set!
Comments
0 comments
Please sign in to leave a comment.