dotnet / dotnet/docfx

Please could compatibility be taken more seriously?

Open
#9,691 2 comments 30 reactions 0 assignees View on GitHub
Dominant language
C#
Stars
4.4k
Forks
890
Avg merge
2h 11m
Merged PRs (30d)
10

Description

I've just spent many hours today upgrading NodaTime from 2.62.2 to 2.75.2. I'm *mostly* there now, but I've just run into a problem with version support disappearing between the two.

I've eventually found where this happened - in [a commit](https://github.com/dotnet/docfx/commit/540e023df6415306e8a3b074ca37b7334a1c8536#diff-a9a27546475658680affb2837ca3c3051a3f02d4e32590556c5edac6fbe04953) with a title of "refactor: rename config property to match json", which apparently failed in CI and wasn't in a pull request (was it even reviewed)?

It removes properties from `FileMappingItem`, including `VersionName` (with JSON representation `version`) and then removes the use of that. How does that count as a refactoring? This change was then released in a patch release.

I've lost hope of there not being any breaking changes in docfx within a major version, but I'd *really* appreciate it if:

- Breaking changes are only introduced in *minor* versions at least rather than patch
- Every breaking change comes with details of how users are meant to migrate, or an acknowledgement that features are simply being removed with no migration path
- More attention is paid to conventional commits so that "refactoring" commits really don't introduce breaking changes

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.