Please Use Beta Packaging Commands

[shetzel]

All packaging beta commands are implemented in plugin-packaging and ready for non-CI use. The current, non-beta packaging commands from the salesforce-alm plugin are deprecated and will display a warning when you use them. We plan to switch those commands to be "legacy" and the current beta commands to the production versions the first week in January, 2023.

Please ensure the beta commands work with your usual packaging flows so the transition from beta to production is as smooth as possible for everyone. If you find any issues with the beta packaging commands, please create a bug report here with the output of sfdx version --verbose and the steps to reproduce the problem. I would not use the beta commands in your CI scripts unless that is the best way to ensure your flows, and only temporarily.

All packaging beta commands have a beta subtopic. E.g., force:package:beta:* and force:package1:beta:*. As a reminder, the which command can be useful to know which plugin owns the command you're using. E.g., sfdx which force:package:version:create. This will be particularly useful when the beta commands become the production versions.

The packaging commands are the last set of production commands from the salesforce-alm plugin. Once the packaging commands in the salesforce-alm plugin are switched to legacy there will be about a month of time before that plugin is no longer bundled with the CLI as a core plugin. It will still be possible to install that plugin separately if there is a need.

Thanks everyone!

[faradeen-ja]

☑️

[cromwellryan]

@AndrewRayCode @bdovh @renatoliveira and @antempus, I noticed your 👎🏼 response on the message above. Can you share more on your experiences with the new Packaging commands?

[renatoliveira]

@AndrewRayCode @bdovh @renatoliveira and @antempus, I noticed your 👎🏼 response on the message above. Can you share more on your experiences with the new Packaging commands?

My issue is with the naming of the commands. Recently I had an issue with the force:package:version:create command and could only make it work with adding the "beta" in the middle. Instead of having a "beta" word added to the command, why not release a beta version of the CLI instead?

Having the command change means that I'll have to change my CI process (e.g: gitlab ci script) now and possibly in the future as well, when the command is no longer beta, or the beta command is no longer available because the stable one now uses the code that was previously beta?

This is just my opinion, but the title of this issue could've been "use the beta version of the CLI" (in case you find errors with your current process). Would still have to change a version number somewhere (like in a Docker image that is used by the CI runner or whatever), but at least wouldn't have to change the script itself or try to guess which version works with which version of my package's metadata.

I didn't like how Salesforce approached this. And I definitely don't like how Salesforce supports developers working with the CLI to build packages that are/will be on the AppExchange. For example, I had the support agent tell me "sorry but your support level is not high enough for us to continue this investigation" and literally copy and paste a Java stack trace from the platform's back end instead.

[cromwellryan]

Thanks for the feedback @renatoliveira!

Recently I had an issue with the force:package:version:create command and could only make it work with adding the "beta" in the middle.

Sorry you ran into trouble with the current commands. A primary reason for these new commands is to improve the quality and reliability of packaging commands. That you were able to find success with the new commands suggests we're achieving that goal.

These commands will replace the existing commands in the near future. Folks currently using force:package:version:create, for example, will soon be using the new commands without any change. That you had an issue in the current commands and needed to move to beta commands is unfortunate and we're sorry. We alias :beta commands when they go GA so that you can make the move back whenever you are comfortable.

why not release a beta version of the CLI instead

That certainly could have been an option for our beta pattern. We chose beta commands for various reasons. If you're uncomfortable using beta commands–we completely understand.

I had the support agent tell me "sorry but your support level is not high enough for us to continue this investigation" and literally copy and paste a Java stack trace from the platform's back end instead.

I'm sorry you had that experience. Contact me directly with the case information–my email is rcromwell.

[bdovh]

This is very frustrating, I have open SF Support ticket for more than a month and I couldn't get a clear answer which package commands should be used: alm old ones or beta commands. Certain different cases are failing in either of these and SF support provides contradictory answer to the question which commands should be used in production

[bdovh]

@AndrewRayCode @bdovh @renatoliveira and @antempus, I noticed your 👎🏼 response on the message above. Can you share more on your experiences with the new Packaging commands?

My issue is with the naming of the commands. Recently I had an issue with the force:package:version:create command and could only make it work with adding the "beta" in the middle. Instead of having a "beta" word added to the command, why not release a beta version of the CLI instead?

Having the command change means that I'll have to change my CI process (e.g: gitlab ci script) now and possibly in the future as well, when the command is no longer beta, or the beta command is no longer available because the stable one now uses the code that was previously beta?

This is just my opinion, but the title of this issue could've been "use the beta version of the CLI" (in case you find errors with your current process). Would still have to change a version number somewhere (like in a Docker image that is used by the CI runner or whatever), but at least wouldn't have to change the script itself or try to guess which version works with which version of my package's metadata.

I didn't like how Salesforce approached this. And I definitely don't like how Salesforce supports developers working with the CLI to build packages that are/will be on the AppExchange. For example, I had the support agent tell me "sorry but your support level is not high enough for us to continue this investigation" and literally copy and paste a Java stack trace from the platform's back end instead.

I have similar case. My github action CI started failing without any particular reason (using old alm commands).
This blocked our development and continuous delivery process (in the middle of the major release).
I spent a lot of time to change my github action production CI to replace every package alm commands with beta commands hoping that would provide me a stable production development and continuous delivery process.
Then I had again multiple errors with installation and uninstallation in my github action production CI which blocked AGAIN our development and continuous delivery process (still in the middle of the major release). :-( I felt very frustrated because I also spent a huge amount of time to discuss these issues with Salesforce support and received no real support or mitigation plan to get a STABLE packaging commands to unblock my production github action CI and my development and continuous delivery process.

Because of all of these problems I had to overtime to get major release done for our customers, staying till the midnight and I don't like it.

[AndrewRayCode]

[] I noticed your 👎🏼 response on the message above. Can you share more on your experiences with the new Packaging commands?

I don't recall, I think it was was because I was trying to set up scratch orgs, and both sfdx and Salesforce are flakey, and someone suggested using the beta commands instead of the current ones, which didn't fix anything, and who knows what it changes under the hood. That, combined with sfdx still returning successful status codes when errors happens, it's a dangerous combination to try to rely on for CI/CD.

[AndrewRayCode]

And frankly, I guess, sfdx updates can be scary. You may recall the 7.112 incident, where a "minor" version bump introduced significant breaking changes #1112

Or the recurring issues that happened from updating the progress bar #289

Or discarding stack traces after an update #807

Or flat out breaking the Docker image #1123

Or the sfdx version that auto-deleted itself and had to be completely ripped out by the roots to fix #1104

And who can forget about the sfdx-vscode extension deleting all my local files. forcedotcom/salesforcedx-vscode#1210 No post mortem on that one either.

Even now the latest "minor" version bump breaks CI because it changes sfdx core flags #1839

Which is why I chose to file #718 - users experience a lot of issues from running sfdx from one day to another because of the auto-update feature.

All of this is exacerbated by instability of the Edge network, and scratch org infrastructure. The ongoing multi-month scratch org outage is probably what lead me to this ticket in the first place. And we all know there isn't overlap between Salesforce support and sfdx, I wish SF support and Trailhead groups pointed to Github immediately, there should be no information or communication about sfdx issues outside of Github.

We have asked for customer facing post mortems on issues like these, but I don't think I've seen any, so it's hard to know how breaking changes like these are addressed and reviewed to improve end user stability.

Now there are commands introduced with beta in the name - a whole new namespace, and because salesforce scratch org and network infrastructure is flakey, and because sfdx gives non-deterministic errors, I'm not confident I could determine what issues are existing vs which are from the update.

Even pinning the sfdx version doesn't work because it drifts from other internal parts of the Salesforce ecosystem that customers can't see. Maintaining working CI is both a big time commitment and a potential risk, all code shipping can come to a halt from an sfdx upgrade.

I don't know if this is helpful, it's how I react when I see "beta" in sfdx commands, and it doesn't look like there's release notes? So I'm just kind of bracing for what's next.

[antempus]

I'm new salesforce as admin/developer/DevOps and the experience has been really rough, not only day to day deltas that @AndrewRayCode, but also on the way commands work between beta and not beta topics.

Generally my issues are from a few sources:

• The differences between the non beta topic commands either working entirely or emitting better errors for debugging/fixing.
• The outputs examples from the documentation have drifted from what's available on the developer site, a minor but memorable example would be setting up the scratch org shapes. (while this issue is for packaging specific, it bears mentioning)
• The deprecation of the non beta topics while the beta commands aren't at the same level of quality is a cause for concern.

I'm of the opinion that if you're going to both deprecate the existing while still working on the beta / future versions, it should not be done in the main release channel of the CLI as @renatoliveira mentioned and while I work on the source compilation for our instance for deployment, it sounds like I'm going to be in for some pain like @bdovh is.

[cromwellryan]

First, thank you 🙇🏼‍♂️ for responding. We understand the Salesforce CLI and the choices we make have a direct impact on individuals. Our mission is to provide a stable and continually improving tool that enables you all.

Beta / Legacy Purpose

Balancing stability and new development is a delicate task. The :beta: and :legacy: command name prefix is among a handful of techniques available to command developers. Commands delivered with :beta: prefixes are intended to give command developers an opportunity to validate potentially disruptive new functionality. That includes new commands, significant changes to existing commands, etc. The inclusion of :beta: commands within the Salesforce CLI(s) provides visibility and accessibility to those commands with minimal overhead. Installing pre-release plugins, Release Candidate (RC) versions of the CLI, etc. are some of the other techniques available.

Legacy commands are commands prefixed with :legacy:. These commands are provided when a command is replaced. We encourage this pattern to ensure any unexpected regression in new commands can be quickly dealt with by customers. Our hope and expectation is that :legacy: commands are never needed, but we acknowledge the risk and want to be safe.

We only include beta commands in the CLI that we believe are ready for community feedback. We do not recommend using :beta: commands for production purposes. We do recommend testing :beta: commands if you are able. The feedback we’ve received from the community has been incredibly valuable and we’re very thankful.

What we could have done better

There are a few things we’ve learned from the new Packaging commands Beta period. Both involve how we’ve communicated with our community. We hear you and want to get better.

Message on current GA packaging commands

The warning message we provided on existing, GA packaging commands led to confusion. The message suggested that these commands are no longer supported, when, in fact, they are supported per our deprecation policy. In reality, the new commands are part of our support process. The existing packaging commands are quite old, hard to maintain, contain bugs, and not open source. The message on existing commands was intended to encourage use of the new, open source, beta commands so we could deliver rock 🪨 solid, open source versions to you as soon as possible. Our messaging wasn't clear. We’ll do better in the future.

Case Language
Some packaging developers experienced issues over the same period in which our beta commands were available. During this period we and support engineers encouraged some of you to try the beta commands. Unfortunately, the beta commands didn't resolve your problems and you were stuck. This led to understandable frustration. We worked quickly to resolve the problems in the beta commands, but didn't make it clear where you should expect to find the fixes. We’ll do better in the future.

Beta / Legacy Process

It’s important that we are clear about the Beta / Legacy process that we follow and recommend plugin developers follow.

:beta: commands are promoted to General Availability (GA) by removing the :beta: prefix. When this happens, an alias for should be created for the :beta: command name so that it can be referred to by both the :beta: and non-:beta: name. That alias should exist at least in accordance with the CLI Deprecation Policy to support customers who chose to use the :beta: commands in scripts.

Commands being replaced using the Beta / Legacy process should be semantically (name, flags, etc) and functionality equivalent. The new command should be a drop-in replacement for the previous. These new commands may gain new or improved functionality via flags, stdout messaging, additional JSON properties, etc. Note that --json responses are backwards compatible and should be used for automation instead of stdout.

Commands that are replaced should include a :legacy: prefix at GA to provide safeguards against regressions in recently GA’ed beta commands. These :legacy: commands should be delivered side-by-side with the new GA command initially. Installable versions of legacy commands can be provided for a longer period if necessary.

[sirephil]

We understand the Salesforce CLI and the choices we make have a direct impact on individuals

Not just individuals, but a huge pool of users, globally.

Beta/Legacy Process

I do not understand the approach of actually changing the command. This requires invasive changes to all the scripting that all the users write around these commands.

It seems to me a better practice to:

• Introduce a switch (such as "--experimental") onto the CLI command.
• Support defaulting of this switch, perhaps at the command level and perhaps universally, via the environment (CLI preferences file, actual environment variables, some other way - I don't care which, but importantly such that you don't need to update scripts to select the flavour to use).
• Simply replace the standard implementation with the experimental one once it is production ready then start diverging the implementation again as further experimentation is done.