Support SemVer

[MaxymVlasov]

Is your feature request related to a problem? Please describe. As you make mostly increment version updates, it's difficult to understand w/o checking the full Changelog diff between the 2 versions to understand what kind of changes we should expect after applying the new version

Describe the solution you'd like Use semver.org for future releases

Describe the use-cases if possible Simplify the update process, as PATCH means fixes issues in the codebase, while MINOR release means that there could be some new (sometimes buggy) functionality. Hopefully, there were no breaking changes yet released as patches or minors but currently we can't trust your release tags as you specify features like "Supported service" as patches

Additional context

This is PATCH, but according to SemVer it should be MINOR - https://github.com/fivetran/terraform-provider-fivetran/blob/main/CHANGELOG.md#1111

True PATCHes exist too - https://github.com/fivetran/terraform-provider-fivetran/blob/main/CHANGELOG.md#113

In any case, thank you for the Terraform provider for fivetran.

[beevital]

@MaxymVlasov thank you for bringing it up. Currently we considering any changes that doesn't force users to migrate their existing configurations as minor changes. Like if we added support for more service types, or more fields - it doesn't affect any existing config, and even there's no need to migrate the state. And they are released as minors.

As our provider schema is based on Open API schema for our API we release a new version once a week or two, and there's no any major changes, so all these releases are minors.

We are currently in a process of migration from terraform-sdk-v2 to terraform-provider-framework, and intermediate releases can't be majors, as they usually brings new issues. Some cases we can't even reproduce and test, so we have to rely on customers who can just test new releases.

I'm thinking about to introduce some kind of "latest-stable" version. Because it's very hard to follow SemVer policy sometimes. And it easier to say - "use this version in prod - it's stable"

[MaxymVlasov]

I'm thinking about to introduce some kind of "latest-stable" version. Because it's very hard to follow SemVer policy sometimes. And it easier to say - "use this version in prod - it's stable"

It sounds like a problem with tests :thinking: But you're right, in some cases, it can be a good solution.

In my case, we use Renovatebot which waits at least 3 days after release before open PR, to be sure that there is no new pending releases which could hotfix problems in prev release. In most cases, that is enough for us. And we perform these updates every week, so if you plan to track which version is stable not in a SemVer way, that will mean that we will need to introduce crutches to get that info, or just stick to the "latest available" till we get some problems

[beevital]

It sounds like a problem with tests

Yes, most issues are related with not enough testing. We also working on this. But with terraform and Fivetran there are so many cases we can't even imagine. We have ~500 different sources supported and each can have it's own issues.

This year we had to release several versions in a row mostly because of issues caused by migration on a new framework, and it's totally lack of testing.

[beevital]

In my case, we use Renovatebot which waits at least 3 days after release before open PR, to be sure that there is no new pending releases which could hotfix problems in prev release. In most cases, that is enough for us.

hah, interesting solution.

[beevital]

I'm closing the issue as there's no any outcome. We just agree that we should follow SemVer versioning policy.