NightOwl888 commented on PR #866: URL: https://github.com/apache/lucenenet/pull/866#issuecomment-1754431922
Thanks for the PR. One issue we had when we tried this on Azure DevOps was it wasn't set up right to correctly detect an upgrade or change of a dependency and when we did a "normal" upgrade of a dependency it failed. The only way I found out of that scenario was to remove the caching and add an explicit download location in NuGet.config. I have read somewhere that packages.lock.json isn't consistently generated across machines, which makes them change too often to keep in source control because they show up as changed files even when no dependencies have changes. Also, having these extra files seems a bit odd when we have a dependencies.props file that can be used as part of the cache key (we would also need to include all *.csproj and all *.targets files to get all of the references). Whatever the case, we need a solid procedure for upgrading or changing dependencies so we don't shoot ourselves in the foot (again) when upgrading. We are likely going to be juggling dependencies around more often from now until the release than we have done so in the past. If we stick with the packages.lock.json files, it would be nice to know how to update them and when to commit them. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
