Open VisualMelon opened 4 years ago
I think pre-release nugets would be preferable since people will need OxyPlot's binary packages anyway.
Connected an Azure Pipelines NuGet feed to the master
branch of the following repository, so the packages can be installed by using a nuget.config
file and importing the following package feed. Probably we could create a separate prerelease feed for another branch or just continue committing to master (worth uploading the current stable version to NuGet.org btw)
@objorke could you please upload a newer version of OxyPlot.Avalonia
to NuGet.org? Probably the one which was built by our new Microsoft Azure CI/CD today based on the latest commits in the master
branch https://worldbeater.visualstudio.com/OxyPlot.Avalonia/_packaging?_a=package&feed=OxyPlot.Avalonia-CI&package=OxyPlot.Avalonia&protocolType=NuGet&version=2.1.0-20200605.6 Btw our accounts on NuGet.org are worldbeater (me) and kekekeks (@kekekeks) if you find it preferable to just grant the permissions to update the OxyPlot.Avalonia
package to us. Thanks in advance! :heart:
@worldbeater and @kekekeks: I have added you as owners of OxyPlot.Avalonia
! Please update the package!
Going forward, I think that more regular pre-release packages for OxyPlot and its satellites like OxyPlot-Avalonia is the best way to keep everything current.
Excuse me if this is a silly and only slightly related question ; why is Avalonia in separate repo in the first place and not in core OxyPlot repo? There is a bunch of backends there already, what is the criteria for deciding to add to that list versus make new repo?
@rafntor there are no specific criteria, it's just how it is and there isn't much reason to change it: adding more platforms to the main repo would ensure they are all up to date, but would make it much harder to maintain the core repo, and make the (already slow) development even slower because the barrier to entry for new contributors will be higher. Apart from the new Skia stuff (which works with WPF and could be used as a basis for other platforms) the tendency has been to move things out of the core repo to make maintenance easier.
OxyPlot.Core is changing quite a bit at the moment, and it will require some effort to update it upon the next release of OxyPlot to NuGet. I would be more than happy to do much of this work - I'm (very slowly) evaluating Avalonia and I reckon OxyPlot.Avalonia would benefit from some recent/on-going additions to the main library - but to do that in a sensible manner requires this repo reference pre-release versions of OxyPlot. There are two obvious ways to do this:
develop
Either option would create some difficulty for users consuming pre-release versions of OxyPlot.Avalonia, but if they can work out how to do that, it shouldn't be a too big an issue to pick up a pre-release version of OxyPlot.Core either. I prefer the second option for a number of reasons (fewer changes, less complexity for contributors, ability to update incrementally) but I wonder if other people have a better idea, or can explain why that would be a bad idea.