Changelog for the Keyman Legacy Bundle dependency#1436
Conversation
|
I put this in the released version, but I can moved it to Unreleased, if desired. Also, @andrew-polk mentioned that this change was breaking. I either missed or forgot that, and how it was. I am happy to document this, if someone can help me improve the wording. |
tombogle
left a comment
There was a problem hiding this comment.
Reviewed all commit messages.
Reviewable status: 0 of 1 files reviewed, 1 unresolved discussion (waiting on @andrew-polk)
CHANGELOG.md line 77 at r1 (raw file):
- [SIL.Core] BREAKING CHANGE (potentially): Changed behavior of DateTimeExtensions.ParseDateTimePermissivelyWithException (now deprecated) to try to interpret the date according to either the Gregorian calendar or the Buddhist calender in order to get the date to fall within a reasonable expected range (from 1/1/1900 through one day in the future). This means that depending on the current culture, dates might be interpreted differently from before. The known places in SIL code where this method is used seems to be for dates in the recent past (modern times); hence the default range. A new overload was added that will allow callers with other needs to specify a different range. - [SIL.Windows.Forms] BREAKING CHANGE: ImageToolbox Removed support for Linux due to no longer using DialogAdapters. Affects `OpenFileDialogWithViews` - [SIL.Windows.Forms.Keyboarding] Moved Keyman legacy libraries to Nuget to fix runtime errors in modern .NET builds.
This should indicate that this is a breaking change since it requires package references to be updated. According to Semantic Versioning (SemVer), moving DLLs from one package to a separate package is considered a breaking change.
Package consumers may rely on transitive dependencies being directly referenced. When you move the DLL, consumers who had build-time or runtime expectations (e.g., direct assembly references, reflection loading, or copying to output) may now experience failures or missing references if they don’t update their dependencies explicitly.
Restore/build behavior can change. Some consumers may have constraints or tooling that doesn’t handle transitive dependency resolution well, especially in older environments (e.g., .NET Framework projects with packages.config or legacy MSBuild behavior).
85b0749 to
2743a73
Compare
|
Changed. I'm sure you're right, but keep in mind that the DLL and its output location is the same. Can consumers reference its place in the repo? Not normal ones. Anyone depending on those DLL's, given how they were included, would have had to be referencing where all the libpalaso and related lib's were being resolved to, even for direct referencing, copying to output, etc., and this didn't change. I guess unless they set up their project to be dependent on the libpalaso source itself, i.e. in a particular folder, and if they happen to be referencing the DLL's where they were checked in, then this would break. I just feel bad for them. |
tombogle
left a comment
There was a problem hiding this comment.
When I updated to the new version, it (automatically) added a reference to my packages.config file. It didn't require a change to any of my code or installer. But I guess the way SemVer defines it, that was a "breaking change." It's ever so slightly possibly that there are other subtle aspects to the change which could break something, but in this case, probably not.
Reviewed 1 of 1 files at r2, all commit messages.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on @andrew-polk)
andrew-polk
left a comment
There was a problem hiding this comment.
Sorry; it has been too long since I did this. I don't remember any details.
I think I remember it caused build failures. But maybe something just didn't update correctly the first time?
Thanks for adding this.
Reviewed 1 of 1 files at r2, all commit messages.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on @josephmyers)
Closes #1434
This change is