Releases: dotnet/reproducible-builds
v1.2.25
This release is designed to be a "cleanup" release that we can use as a solid foundation to build on. We've cleared the backlog of PRs and resolved several issues. Two changes of note:
- The minimum required SDK version is now .NET 8
- The
RepositoryBranch
logic introduced in v1.2.4 has been refactored to align with the values provided by Source Link in .NET 9
Removals
- Bump required SDK to 8+ and remove fixed issues by @MattKotsenas in #52
What's changed
- Align RepositoryBranch logic with .NET 9 by @MattKotsenas in #50
Tidying up
- Clean up README and add status badges by @MattKotsenas in #41
- fix References link by @bergren2 in #38
- Migrate from SignClient to
sign
tool and specify SDK in global.json by @MattKotsenas in #43 - Add tests for package by @MattKotsenas in #47
- Add CODEOWNERS by @MattKotsenas in #48
- Add test cases for detecting CI environments and setting ContinuousIntegrationBuild by @MattKotsenas in #49
- Shorten up the DotNet.ReproducibleBuilds package props file. by @AraHaan in #11
New Contributors
Full Changelog: v1.2.4...v1.2.25
v1.2.4
At long last we've have a new release of the DotNet.ReproducibleBuilds
and DotNet.ReproducibleBuilds.Isolated
packages! We've dusted off the cobwebs and worked through some infrastructure and permissions issues, and now have the ability to reliably release new versions of the packages again. This is due in no small part to the help of our brand new maintainer - welcome to @MattKotsenas! He and I will be working together to develop a plan for this repo going forward, and I'm very excited to welcome him to the maintainer team.
This release has a few new features and one feature removal due to obsoletion.
Additions
- Set the
DisableImplicitLibraryPacks
property totrue
to prevent using packages from the .NET SDK's built-in package sources. #21 (Thanks @cmeeren!) - Populate the
RepositoryBranch
property if other Repository Metadata has been requested to be made public. #27 (Thanks @kzu!)
Removals
- No longer include the .NET Framework reference assembly packages, because the .NET SDK does this now. #33 (Thanks @MattKotsenas!)
Infrastructure
We have simplified the packaging of the repo to be more straightforward, using dotnet pack
as expected these days.