Class-transformer: question: Why do you release a patch version with breaking changes

[kevincodecookies]

Description

patch release with a breaking change

Minimal code-snippet showcasing the problem
just use the package like described by https://docs.npmjs.com/cli/v6/using-npm/semver#caret-ranges-123-025-004

Expected behavior

no breaking changes on patch lvl releases

Actual behavior

the version 0.3.2 has breaking changes as it moves and refactors an exported type (ClassType to ClassConstructor) and changes the signature of @Transform decorator (@Transform(value => //do something) to @Transform(({value}) => //do something))

Recommendation

only do breaking changes on major lvl or on minor lvl if we are still on 0.someNumber.someNumber so that people using "^" can use the package correctly. like described here : https://docs.npmjs.com/cli/v6/using-npm/semver#caret-ranges-123-025-004

[AckerApple]

It looks like changes are under way for this looking at the logs here. At this time npm still has breaking version

my recommendation to fix now to prevent further auto injecting of bad version is to:
Release a version 0.3.3 that reverts the breaking changes AND THEN release a new version called 0.4.0 with the new breaking changed

To prevent ourselves from auto installing these breaking changes, lock your dependency down by removing ^ or ~ such as from ~0.3.0

This is also a great time to be thankful for this library and its maintainers. I could not find a donate link but welcome any chance to give back.

I mentioned this very same issue but mine was closed for who knows why?

[takayukioda]

I'm up to the idea "not include breaking change in patch version" too.

@NoNameProvided I agree to your idea that "library user should check changelog before update" (mentioned in https://github.com/typestack/class-transformer/issues/547#issuecomment-760451441) but it seems that you are missing following scenario.

Let's say, user were using socket-controllers in user service and reflect-metadata released breaking change in "0.1.14". Even if user lock reflect-metadata's version to "0.1.13", breaking change still slip through because socket-controllers dependency is not been locked (^0.1.13). In this scenario, user can't control which version to use.
That's why I believe it's better to not release any breaking changes in patch version. Even when major version is zero.

I hope this scenario is convincible enough to fix this breaking change.
I would love to hear your thoughts.

[AckerApple]

As a maintainer of 30 packages, I would:

• download v0.3.1 from npm
• Publish v0.3.1 as v0.3.3 to overwrite breaking changes
• Download v0.3.2 from npm
• Release v0.3.2 as v0.4.0

No code changes. Let’s all make a mental note of this course of action to assist any package that has released breaking changes as a PATCH version (cause it’s never too late)

[WSanders31]

As a maintainer of 30 packages, I would:

• download v0.3.1 from npm
• Publish v0.3.1 as v0.3.3 to overwrite breaking changes
• Download v0.3.2 from npm
• Release v0.3.2 as v0.4.0

No code changes. Let’s all make a mental note of this course of action to assist any package that has released breaking changes as a PATCH version (cause it’s never too late)

As someone who has already updated our source to utilize the new changes from v0.3.2, I for one, am terrified.

Thanks for all the work on class-transformer to those involved - do appreciate it. <3

[AckerApple]

@WSanders31 heads up of where we had issue AFTER SUCCESSFUL build:

Used to work:

@Transform(parseInt)

No build errors occurred. Went through unit tests and luckily 200 was expected but 400 thrown for something like “cannot parse object”

Had to change to:

@Transform((ob: TransformFnParams) => parseInt(ob.value))

[gerryburtenshaw]

Breaking changes should result in a Major Release version update (not minor, or, in this case, patch)
So, these changes should have been released as a v1.0.0 (WRONG - see below)

Addendum - The presence of a pre-release tag (-alpha, -beta) indicates substantial risk, as does a major number of zero (0.y.z), which is used to indicate a work-in-progress that may contain any level of potentially breaking changes (highest risk).

[AckerApple]

@gerryburtenshaw i saw you updated your comment. I didn’t really agree with it at first and now I disagree with it more

Throw out your rule book because a package with 572,670 weekly downloads shouldn’t lean on the excuse of being in version zero.

Second, a lot of coders do not agree with changing the MAJOR version number for every breaking change. It would have saved a lot of Angulars reputation if it was 2.11 instead of 11.0.

In life I never take rules as being perfect

[NoNameProvided]

0.4.0 has been released, 0.3.2 has been deprecated with a warning message:

This release contains a breaking change from 0.3.1 but otherwise functions properly. Please read the changelog on Github to learn more.

Closing this as solved.

[gerryburtenshaw]

@AckerApple - I totally agree with you - I too was expecting the v1+ behaviour and not 0.x.y environment - I was only parroting the standard (which was previously mentioned)

In terms of rules, if the tools are enforcing them, then you kinda have to work within those constraints. Either your dancing with the devil or doing to 2-step around him.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.