Releases: NuKeeperDotNet/NuKeeper
Version 0.11.0
UsePrerelease
option to control update to pre-release versions,Always
,Never
orFromPrerelease
.FromPrerelease
is the previous behaviour and is the default. #583 from @cswendrowski- Packages published with a future date are allowed when using
--age 0
#597 from @cswendrowski - Relative path support or local repo #600 from @MarcBruins
- Support for org mode in self-hosted bitbucket #589 from @Jens-H-Eriksen
- Handling Directory.Build.props/targets #599 from @skolima
Version 0.10.3
- fix a bug introduced in
0.10.2
that caused a crash when logging some errors #578 - test out new Azure Devops build and deploy pipeline that @MarcBruins built
Version 0.10.2
Version 0.10.1
Some fixes and improvements to version 0.10
- fix for issue where nuspec files were written incorrectly sometimes, due to contents being overwritten not replaced. ( #552)
- Support for TFS Server ( #550 )
repo
command can work on local file folders and locate the git remote, in some cases (for AzureDevops), ( #533, #545 )- When package are filtered out due to minimum package age, or due to include/exclude, there is more detailed logged of which of these stages causes them to be filtered out ( #548, #557)
- More details logged of failures in the Azure Devops Rest Client ( #555, #558 #562 )
- Internal review, refactoring etc.
Version 0.10.0
This release changes the paradigm - the back end collaboration platform can be GitHub, AzureDevops or BitBucket.
The repo
url can be any of these platforms, and will be detected based on keywords in it - github
, dev.azure.com
, visualstudio.com
, bitbucket.org
Huge thanks to collaborators @MarcBruins and @shep1987 who did this code
and took NuKeeper in an amazing new direction.
This code is quite early and will likely be improved in following releases. Other back ends are also possible with the new model.
Version 0.9.2
- a lot of internal refactoring and re-arrangement to prepare for back-ends that are not GitHub, starting with Azure Devops (i.e. preparation for #489). Big thanks to @shep1987 and @MarcBruins for this!
- Udate
libgit2sharp
to version "0.26.0-preview-0054"
Version 0.9.1
A couple of fixes and improvements
- Improve wording on a consolidated multipackage Pull Request ( #479 )
- A repeatably unique name for a multipackage Pull Request (also #479 )
logdestination
option ( #481 ). This is fully documented in Configuration
Version 0.9.0
Release 0.9.0 has the following changes:
-
The tool name and package name is now
nukeeper
in all lower case. This is a mitigation for issue #433 and similar. -
Output formats and destination system is in place. This is for using NuKeeper as a tool to generate data about possible package updates, making this flexible and having a variety of human and machine-readable formats. This design started with issue #331 and entirely replaces the CSV report option.
- All text written is either part of "logging" or "output". Both can be individually sent to console or to file. Logging has verbosity levels, output has several possible formats.
- Logging can be sent to file with
--logfile somefile.log
- The
--outputdestination
allows output to be sent to one ofConsole
,File
or turnedOff
. OutputFileName
can be specified to send output to the named file.OutputFormat
can be one ofText
(i.e. human-readable),Csv
,Libyears
orNone
.
-
We use Rosyln analysers to catch issue in the source code. Many small changes were made, the majority around string matching and current culture. This should not be user-visible, and hopefully only improvements result.
Version 0.8.1
Fix to bug #453 Regression: command line fork mode ignored in 8.0.0
Version 0.8.0
- The two ASP.NET metapackages,
Microsoft.AspNetCore.App
andMicrosoft.AspNetCore.All
, should not be updated, rather using them with an explicit version should be warned. #436 , #443. Code from @slang25 --consolidate
flag to produce 1 PR containing multiple package updates instead of the default of 1 PR per update. #450, #421. Code from @Cookie1981- Log to file. -
-logfile somefile.log
will append log output to that file rather then send it to console. #442 - When errors are logged to console, they are red #444