Second-Gen Packaging Migration and Winter 21 release

Question

There is a Salesforce Developers YouTube video from Dec 13th 2019:

Introducing Managed Second-Generation Packages

Which hinted that the Winter 21 release would include:

Enabled migration of first-gen packages to second-gen packages (GA)
Remove any Metadata Type from Managed Package (Pilot)

But looking at the release notes for packages:

Salesforce Winter ’21 Release Notes: Packaging: Package Ancestry Visualizations, Unwanted Package Versions Are Deletable, Push Upgrades Are Generally Available

It seems like they didn't make it into the release.

Does anyone have any insight into the status of these features?
What is the current process for migrating a first-gen package to second-gen?
Is it too late to migrate to second-gen if I've started building the package in a dev org with a namespace, but not uploaded anything yet? (not even a beta)

Mohith Shrivastava · Accepted Answer

For 1 and 2nd items, the work is in progress and cannot publicly disclose the dates.
I recommend you reach to your partner account manager or if you are an ISV reach to your ISV Technical Evangelist to get some idea on when it is going to be released and process.
For your third question below,

Is it too late to migrate to second-gen if I've started building the package in a dev org with a namespace, but not uploaded anything yet? (not even a beta)

No, it is not late, in fact, it is a perfect time to move to 2GP packages.
As long as you do not have a Metadata category that's not going to be ever supported in 2GP you should move to 2GP because of various advantages. There is no point in using 1GP packaging.
The process to get started with 2GP for you is really straight forward.

Enable Dev Hub in your Partner Business Org (Assuming you have this as you are an ISV)

Link your Dev org where you have Namespaced to your Dev Hub org

In your Dev org create an unmanaged package and add all the metadata you plan to package.

Retrieve all the metadata from the package to your local project workspace (use sfdx force:project:create to scaffold a Salesforce DX Project and authorize salesforce CLI with your DevHub and Dev org) using below
sfdx force:source:retrieve -n ""

Create a 2GP Managed package and package versions using packaging commands
sfdx force:package:create 
sfdx force:package:version:create

Key Points to Note in 2GP Packages that are new compared to 1GP

You cannot create 2GP packages using the package manager UI. It is CLI driven and you will need to be comfortable with Salesforce CLI

2GP packages are source driven, meaning the source you have in local is packaged and the source does not reside in org. I recommend you version your source using Git or any other VCS. Read more here

2GP packages can be modular with the ability to break them down into multiple packages and relate them. So spend some time thinking through the architecture of your package for the long term.

2GP Managed packages have the concept of Package Ancestors. This helps to branch your code if needed. Hence it's important you have ancestor tagged before you release the package.

You can use Scratch orgs and use Source Tracking capability to push and pull metadata.

sfdcfox · Answer

Does anyone have any insight into the status of these features?

I don't think anyone can say anything publicly (#SafeHarbor and all that), but I'm sure they're working on it.

What is the current process for migrating a first-gen package to second-gen?

Until the release notes say otherwise, there is no path. Subscribers of First Generation Packages would need to uninstall the old and then install the new. Fortunately, once on the Second Generation Package, there won't be any need to do this migration again. Or, wait until a migration path is available.

Is it too late to migrate to second-gen if I've started building the package in a dev org with a namespace, but not uploaded anything yet? (not even a beta)

Not at all! You can link your namespace to your Dev Hub org, and from there, you can create Second Generation Packages after converting from Metadata API (MDAPI) format to Source format, which is typically as simple as a force:source:retrieve -x or force:mdpai:convert. Note that you can do this even if you had uploaded metadata, it just would not be convertible. I wouldn't recommend maintaining two packages, though; if you're starting fresh, now is the time to start on Second Generation Packaging (unless one or more metadata types are not supported yet). This allows you to create an unlimited number of packages that can all share the same namespace (but remember to use @NamespaceAccessible if you plan on sharing code across packages).

Second-Gen Packaging Migration and Winter 21 release

2 Answers

Add your own answers!

Ask a Question