This message was deleted.

Example 1: Someone want to create a library for setting smart defaults (think reset.css). In 

Pulumi.Azure

 , this could be done by something like:

public class ResourceFactory
{
    public Account StorageAccount(string name, AccountArgs? args = null)
    {
        args ??= new AccountArgs();

        args.ResourceGroupName = _resourceGroupName;
        args.Location ??= _locationInput;
        args.AccountKind ??= "StorageV2";
        args.AccountReplicationType ??= "LRS";
        args.AccountTier ??= "Standard";

        return new Account(name, args);
    }
}

But in order to do this with 

Pulumi.AzureNextGen

 , the developer now has to create an overload for every version? And even if they did, when a new API version was released, the library would be broken until the developer add additional overloads.

Yeah, that’s a trade-off to make. 1. Azure Go SDK does that. 2. arm2pulumi would be really challenging without multiple versions. 3. “Latest” is quite often a lemon as Azure rolls out new versions. We’d have to manually pick “the best version”. 4. We’d also have to force upgrades on everyone as we make those decisions, which creates friction. High-level libraries likely need to pick a version for each resource and stick with it for a while.

@tall-librarian-49374 What do you think of this? Packages: Packages are broken up, like the below. Note that non-version-named packages like

Pulumi.AzureNextGen.Web

represent the latest stable releases, but drop the identifier since it should be obvious now (and ideally is dropped from the namespace as well). Pulumi.AzureNextGen.Web Pulumi.AzureNextGen.Web.V20180201 Pulumi.AzureNextGen.Web.V20200601 Pulumi.AzureNextGen.Storage Pulumi.AzureNextGen.Storage.V20190601 Pulumi.AzureNextGen.Storage.V20200801Preview Pulimi.AzureNextGen - Contains the latest packages - Pulumi.AzureNextGen.Storage - Pulumi.AzureNextGen.Web - ... Pulumi.AzureNextGen.All - Contains all old and new sub-packages - Pulumi.AzureNextGen.Web - Pulumi.AzureNextGen.Web.V20180201 - Pulumi.AzureNextGen.Web.V20200601 - Pulumi.AzureNextGen.Storage - Pulumi.AzureNextGen.Storage.V20190601 - Pulumi.AzureNextGen.Storage.V20200801Preview - ... Versioning: [Update] The major version of "latest" packages corresponds to the newest API version 20200601.0.0 20210601.0.0 The major version of "latest" packages updates with each API version change. Using the above

Pulumi.AzureNextGen.Web

as an example v1.0.0 contains latest (which would be V20200601) v1.x.x contains minor/patch changes to the API v2.0.0 contains the next API release (i.e. V20210601) ... Developers should understand SemVer and thus realize that major version changes could mean breaking changes. For

Pulumi.AzureNextGen.Web.V20180201

, maybe continue to use the same versioning scheme in place. Results - Removing

.Latest

makes it much easier to migrate from Pulumi.Azure - Users who just want to use the latest can easily do so - Users are not blindly updated to a new version - Users who want to pin versions can easily do so - Users are not forced to upgrade - Old version-named packages do not need to be republished every time - arm2pulumi can continue as-is without any significant change

What is the benefit of two naming convensions used in parallel (v1.0.0 and V20180201)? Why is semver easier to use?

1.0.0

is not for naming, that is just a potential versioning scheme as

1.0.0

seems more digestible version than

20180201

. But having

20180201

as the major version number is fine too.

Azure-nextgen resources follow the same versioning as the actual azure apis. If the provider were to use semver for the resources instead of, for example, V20200601, pulumi would then be making the decision across the entire azure api surface on what is a breaking change. That decision should be made by the azure team responsible for that api, not pulumi

I don't care if the major version numbers are 1, 2, 3. That was one suggestion and can be ignored. But the major version number should be changed whenever the Azure team puts out a new API version.

20200601

is fine as a major version number.

@early-sugar-1496

a resource only exists in latest and not in a dated namespace

Can you point me to an example? I’m relatively sure that’s not possible and happy to take a look.

@tall-librarian-49374 The package-per-version model would retain the version number in the namespace. I do think we should drop

Latest

from the namespace as it makes migration easier and seems unnecessary for a package that only represents the latest, but that's just my opinion. And ignoring that suggestion doesn't eliminate the other benefits.

Ah I see. So, mostly, everything is the same, just multiple packages.

It also reduces noise and bloat. Why would I want a package that has X different versions, starting from 6 years ago, when I only want one or two of the most recent? It can slow down development as shown in this image. Visual Studio is trying to be helpful by finding namespaces that contain the type name. But it's recommending old versions, because there are just too many options. If I could pin the one or two versions, then it would recommend to me what I actually want.

Makes sense. I wonder if that outweighs the process of discovery of all the NuGet packages that one wants to bring in.

You could always set the meta-package as the default, but searching "Pulumi" in a package feed is pretty easy.