Second Generation Packages - Mismatching Versions

Question

Is it possible to avoid mismatching version during Salesforce transition periods?

Salesforce message

Mismatching Versions.
The AppExchange Application or component you have selected is not yet available on your instance of salesforce.com. Please check back in a few days to retry the installation. Press the back button of your browser now and bookmark the AppExchange Directory page so that you can find it later.

I've generated a package last month and it does work on Spring 20 orgs (v48.0). However, today I generated a new package with no code change at all, and I can't install it on Spring 20 orgs.

I've confirmed that the DevHub has been already upgraded to Summer 20 (v49.0). Is that the reason? Shouldn't it rely on the newest metadata used (API 48)?

I've tried to configure the "project-scratch-def.json" to use the previous release and also tried to generate the package using this definition file.

project-scratch-def.json with release previous

{
    "release": "previous",
    "orgName": "ABC",
    "edition": "Developer",
    "namespace": "myNamespace"
}

Ref: https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_scratch_orgs_def_file.htm

Package version generation command

sfdx force:package:version:create --definitionfile "config/project-scratch-def.json" --package "ABC" --installationkey SuperSecret --codecoverage

Answer 1

Important release notes from Salesforce - Spring 21 onwards

After your Dev Hub org is updated to the Spring ’21 release, you can create packages with the release version set to previous.

Starting in the Summer ’21 release transition, you can specify preview or previous as the release version.

How: To create a package version based on the previous Salesforce release version, create a scratch definition file that contains:

{ 
  "release": "previous"
}

Source: https://help.salesforce.com/articleView?id=release-notes.rn_sfdx_packaging_target_specific_release.htm&type=5&release=230

Answer 2

Salesforce has answered my question:

This is to share that packaging org where the package is developed inherits the feature of the current release.

In your situation, DevHub is in Summer 20, where the package was developed and released and thus when you will try to install the same package in older version, it fails.

So as shared, you shall be able to install it to subscribers org in Summer 20 but not in Spring 20.

I hope it can help you... Thanks