1. Time Allocation
2. Resources
3. Process
   • Step 1: Git Branch Select
   • Step 2: Code change
   • Step 3: Build and Upload
   • Step 4: Add Uploaded Build into CET's latest BETA/RC Build and Testing
   • Step 5: Sign off Process
   • Step 6: Release

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.

Differences and similarities between major and minor releases.

It is recommended for both major and minor releases start migrating 8 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 releases.

It is also 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 6 simple steps to go through migration:

Step 1: Git Branch Select

Switch your git base repository. During the migration process, the beta branch should be used (refer to branch conventions). The branch contains code for the next major or minor release once it becomes available publicly in the distribution 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.

Example

When migrating from version 11.0 to version 11.5, a new class called AODataSkinFrame was implemented in Abstract Office. So in Fika Extension, DataSkinFrame 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 (version 11.0)
public class ExampleImplementationFrame extends DataSkinFrame {

// New (version 11.5) 
public class ExampleImplementationFrame extends AODataSkinFrame {

If for example, you have an implementation called ExampleImplementationFrame extending from DataSkinFrame. Compiling this in 11.5 would result in an "undefined type" error as the DataSkinFrame class is now missing. You would then need to instead extend from AODataSkinFrame.

Step 3: Build and Upload

You can then create a new build by using Build Central in CET Operator.
Within the Build Central in CET Operator, the new build can be uploaded into Build Center on the MyConfigura page.

Step 4: Add Uploaded Build into CET's latest BETA/RC Build and Testing

Once the release's BETA/RC has been announced, place your extension into our CET's latest BETA/RC build. The BETA build is 8 weeks before release, and the RC build is 4 weeks before the release date, as stated in the Time Allocation part of this article.

You can further refer to the Adding Build(s) to a Version article.

Your QA teams will then go through testing using QA Migration Testing Guides.

Step 5: Sign off Process

After your Extension has been tested, the Extension owner or Developer admins (person in charge of 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.

You can find more information in the Signing Off on Extension Testing article.
During major releases, do remember to set the extension's release date as stated in the 5th step of the said article.

Step 6: Release

Once your release is ready to go, you can drop it in the Official Distribution. And you are all set!