Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate/document how to always get latest version of nuget package #1021

Open
ermshiperete opened this issue Dec 3, 2020 · 7 comments
Open

Comments

@ermshiperete
Copy link
Member

Some projects might want to always build with the latest version of a nuget package. This needs to be researched and documented.

  • it looks like nuget has an option to do that (mentioned in NuGet 2.8 Release Notes)
  • another option might be to use the alternative package manager Paket

IMO doing it directly with nuget would be the preferred way because of the integration in the IDEs and tools, which makes it easier to use and less maintenance with new versions.

@jsubloom
Copy link
Contributor

jsubloom commented Dec 7, 2020

Brainstorm: One approach could be to add a Build step in TeamCity that does it. I hypothesize that you could use the NuGet Installer step, and use some clever set of parameters to get it to update a certain set of dependencies to the latest. Inspired by: https://stackoverflow.com/a/15039174/311238
Downside though (or upside, depending on your needs), this wouldn't work on local builds for develoeprs.

@tombogle
Copy link
Contributor

tombogle commented Dec 8, 2020

According to this article, "floating" version numbers are supported:
=> When using the PackageReference format, NuGet also supports using a floating notation, *, for Major, Minor, Patch, and pre-release suffix parts of the number. Floating versions are not supported with the packages.config format. When a floating version is specified, the rule is to resolve to the highest existent version that matches the version description. Examples of floating versions and the resolutions are below.
It seems this would be the way to do it, but it would mean that a different branch with a pinned version specification would be needed for release builds.

@tombogle
Copy link
Contributor

tombogle commented Dec 8, 2020

Maybe we could write a new SIL BuildTask that would be able to go through the PackageReference elements for libpalaso packages and turn hard version numbers into floating version references. Then a .proj file could just have a special target to execute that build task before performing the regular build. A CI build for the active development branch could specify that build target.

@ermshiperete
Copy link
Member Author

I wonder if nuget has something like that built in, or if there is a tool that does that. Because if you update the packages in VS or Rider it'll update the version numbers.

@hatton
Copy link
Member

hatton commented Dec 8, 2020

A different direction would be to use https://github.com/marketplace/actions/nukeeper-action, with the "repo" option, to automatically generate PRs when libpalaso is upgraded.

@andrew-polk
Copy link
Contributor

it would mean that a different branch with a pinned version specification would be needed for release builds.

That would mimic what we do currently, anyway. So if * works, that gives us what we want.

Our current process:
The Alpha channel builds from master branch using latest TC dependencies.
All other channels use release branches which are pinned to specific TC builds for dependencies.

@tombogle
Copy link
Contributor

tombogle commented Dec 8, 2020

A different direction would be to use https://github.com/marketplace/actions/nukeeper-action, with the "repo" option, to automatically generate PRs when libpalaso is upgraded.

Looks like SIL.FwBuildTasks uses WhiteSource Renovate to do this same thing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants