tall-needle-56640
12/07/2020, 6:44 PMPulumi.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.tall-librarian-49374
12/07/2020, 7:04 PMtall-needle-56640
12/07/2020, 8:28 PMPulumi.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
Pulumi.AzureNextGen.Web
as an examplePulumi.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 changetall-librarian-49374
12/07/2020, 8:48 PMtall-needle-56640
12/07/2020, 9:23 PM1.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.Web.Latest
represents V20200601
in some package version x.1, I would not expect Web.Latest
to represent V20210601
in version x.2. The APIs are (potentially) now incompatible. (On a side note, I thought SemVer was pretty industry standard.)early-sugar-1496
12/08/2020, 12:04 AMtall-needle-56640
12/08/2020, 1:13 AM20200601
is fine as a major version number.tall-librarian-49374
12/08/2020, 7:11 AMa resource only exists in latest and not in a dated namespaceCan you point me to an example? I’m relatively sure that’s not possible and happy to take a look.
tall-needle-56640
12/08/2020, 3:07 PMLatest
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.tall-librarian-49374
12/08/2020, 3:12 PMUsers who just want to use the latest can easily do soa bit more straightforward but I’m not sure I see other benefits.
tall-needle-56640
12/08/2020, 3:29 PMtall-librarian-49374
12/08/2020, 3:32 PMtall-needle-56640
12/08/2020, 4:23 PM