2.1 Release Plan

[VisualMelon]

We would like to make a '2.1' release, primarily to make the new Skia rendering provisions generally available, hopefully in the time-frame of a couple of months.

Everything is provisional at the moment. Feedback/edits welcome.

Plan

A plan for a 2.1 release is as follows:

1. Identity any more features or fixes we want in the 2.1 release in the next couple of weeks.
2. Set up a 2.1 branch and release a 2.1-preview1 pre-release to NuGet, making the changes more available to users, with a commitment to not change the APIs and behaviour unnecessarily
3. Continue to test the 2.1-preview1 pre-release and address any bug-reports for a period of a few weeks. Normal development can continue during this period, but only bug-fixes will be cherry-picked into the 2.1 branch (or merged directly, if they are no longer applicable to the develop branch)
4. If deemed necessary (e.g. if there is a large volume of issues with preview1, or some issues require significant work) we may go back to step 2 and release an additional preview to NuGet
5. Once we are happy that the 2.1-previewX release is sufficiently stable, we release it as the 2.1 release to NuGet
6. For some period time (e.g. until we make another substantial release) we continue to endeavour to merge important bug-fixes into the 2.1 branch, and release 2.1.X as necessary

Pending Changes

Things we want to be in 2.1, but haven't done yet:

[ ] Possibly #1556, though it needs some more thorough testing, I think I'm not happy enough [x] Sort out OxyPlot.Contrib in light of the moving of the WPF XAML components there [ ] Update documentation for OxyPlot WPF/XAML

Changes

Important changes:

• Upgrade to .NET Core 3.1 (3.0 is EOL)
• Re-introduced .NET Framework 4.0 support for WinForms and WPF
• Added OxyPlot.SkiaSharp.WPF
• Added OxyPlot.SkiaSharp exporters
• Added Oxyplot.ImageSharp exporters
• Updated OxyPlot.Core.Drawing, now shares its code-base with OxyPlot.WindowsForms
• Consolidate clipping, giving rendering improvements and simplifying the rendering APIs
• Screen-space Axis Margins
• Consolidate transposition of X/Y series and annotations
• Removed ColumnSeries: use BarSeries
• Removed WPF Plot component (moved to Oxyplot.Contrib.Wpf)
• Increase consistently in exporter APIs
• OxyPlot.PdfExporter marked as obsolete (consider OxyPlot.SkiaSharp.PdfExporter instead)

I'll add to this if we make any more big changes, or if anyone wants to point out a stand-out feature or change that should be highlighted. It might be fun to provide comments 'selling' recent changes somewhere (maybe upon release of the preview), so that people can judge whether they need/want to update or not.

The changelog published with the 2.1 release and pre-releases will provide a comprehensive list of changes. I'll put a link to it here when preview 1 is released.

Other

This will provide a good opportunity to bring other platforms up-to-date (e.g. Gtk#, Avalonia). It would be nice to provide corresponding 2.1 releases in the same sort of time-frame, but I think this should be a 'best-effort' rather than a blocking concern. It would be nice to fix the Xamarin provision, which I understand has some issues as of 2.0, but I'm not sure we have anyone who is in a position to test them properly.

[VisualMelon]

@Jonarw @objorke I've finally realised that updating the documentation regarding OxyPlot.Contrib before the proper realise is probably a recipe for disaster (not least because the contrib stuff can't be release until this is). As such, there is nothing I'm working on which I want to see in 2.1-Preview1. It would be nice to see #1687. Is there anything else that would stop us releasing 2.1-Preview1 next weekend (or otherwise at our next convenience)?

Apart from that, the task now will be writing a release document, which can probably just be a slightly more detailed version of the above.

Additionally, is @objorke happy to continue handling NuGet releases, or do we want to set @Jonarw and/or me up with those permissions? (I'm not sure I'd trust me, but I'd definitely trust @Jonarw).

[objorke]

I trust both @VisualMelon and @Jonarw for the NuGet releases! Let me know your NuGet usernames and I will add you as owners.

[VisualMelon]

@objorke I can confirm that I am VisualMelon on NuGet and MyGet. If you could ping me if/when you make any changes, I'll check they haven't gone to someone else by chance.

[objorke]

I have given you access to all 20 packages!

[VisualMelon]

I think I've accepted them all; shout if I've missed any.

[VisualMelon]

Are there any scripts lying around for publishing everything, or is it necessary to manually upload them one at a time?

Also, do we need to create new packages for ImageSharp, SkiaSharp, and SkiaSharp.Wpf?

[objorke]

I have simply used this from Windows command line

nuget setapikey #############################
for %%A in (*.nupkg) DO nuget push %%A -Source nuget.org

or

for %%A in (*.nupkg) DO nuget push %%A -Source nuget.org -ApiKey ###############################

[objorke]

yes, push the packages for ImageSharp and SkiaSharp, too

[VisualMelon]

Made a draft of a release document: https://gist.github.com/VisualMelon/e3b8eaceb91e2cd5430ee5687fc95649

This really doesn't feel like a point release, now that I've enumerate all the breaking changes. Legends alone is a big change that will affect everyone (as opposed to just people using WPF). For people who can't update to 2.1, will there be packaging issues with nuget trying to pull OxyPlot.Core 2.1 as a dependency for OxyPlot.WPF 2.0?

[VisualMelon]

will there be packaging issues with nuget trying to pull OxyPlot.Core 2.1 as a dependency for OxyPlot.WPF 2.0?

I think there will indeed. That is a serious problem which I really should have realised weeks ago: it means releasing 2.1 would break any code which currently references a platform (e.g. OxyPlot.WindowsForms 2.0) but not OxyPlot.Core 2.0 directly. Any suggestions how we could get around this without jumping to 3.0?

[Jonarw]

Is there anything else that would stop us releasing 2.1-Preview1 next weekend (or otherwise at our next convenience)?

Not from my point of view. With #1687 merged, I think there is nothing left I would have liked to see in a potential release.

Let me know your NuGet usernames and I will add you as owners.

I am also Jonarw on both Myget and Nuget. Thanks for your trust!

For people who can't update to 2.1, will there be packaging issues with nuget trying to pull OxyPlot.Core 2.1 as a dependency for OxyPlot.WPF 2.0?

I think there could potentially, but not necessarily, be issues because e.g. OxyPlot.WinForms 2.0.0 requires OxyPlot.Core >= 2.0.0 as dependency. Usually nuget will try and restore the version 2.0.0 for this package ('Lowest applicable version'), so in most cases it should be fine. But under certain circumstances it would also consider the version 2.1.0 (see https://docs.microsoft.com/en-us/nuget/concepts/dependency-resolution for details).

However I guess it would even consider version 3.0.0 in that case, so it also wouldn't help jumping to v3. Whether the amount of breaking changes justifies a major version bump might be a different story, but I don't have a strong opinion about this.

Should we consider using 'Floating versions' (see above link for explanation) in future releases to avoid this kind of issue in the future?

[VisualMelon]

@Jonarw Re-reading that document again in less of a state of panic, I think you are right: it probably won't be an automatic break-all-the-code problem so long as we keep 2.0 available; it will just be the case that almost any code written for 2.0 won't work with 2.1 (because of legends and I've just realised the change in render API), which while not ideal isn't going to cripple the project. I can't imagine why anyone would want to use a 2.0 platform with 2.1 core, so it shouldn't be a problem in practise.

I'm starting to think the best thing to have done would be to release a 2.0 version of the Skia provisions, but would be effort, would be confusing with respect to code sharing in the WPF side of things, and wouldn't be as good as what we can provide in '2.1'. Most of me thinks the only sane thing to do is to bump 2.1 to 3.0 because we are making such significant changes, but that would feel wrong because we really want to make some more serious changes soon. The rest of me thinks that so long as we don't break people's existing projects, the breaking changes - while pervasive - are actually pretty minor, and anybody should be able to patch their own code easily if they need/want to switch, and there is plenty of good stuff to warrant a release.

Realistically, it is unlikely that we are going to provide fixes for bugs in 2.0 now in a 2.* release (we could try to back-porting bug fixes in future), there is lots of good stuff in 2.1, and fundamentally the library hasn't changed since 2.0: it's just that some stuff has shuffled around and couple of APIs have been tweaked slightly, so I should stop worry and we should release 2.1 because while it's not ideal it's significantly better than nothing. Enough typing, on with the plan?

[VisualMelon]

Should we consider using 'Floating versions' (see above link for explanation) in future releases to avoid this kind of issue in the future?

I'm not sure what you mean: something like making 3.0 platforms depend on core = 3.* rather than >= 3.0?

[Jonarw]

and we should release 2.1 because while it's not ideal it's significantly better than nothing. Enough typing, on with the plan?

I would agree. There is no option without drawbacks, but I think our 2.1 plan makes the most sense out of the options we have.

I'm not sure what you mean: something like making 3.0 platforms depend on core = 3.* rather than >= 3.0?

I would have considered that packages from the 2.1 release that depend on OxyPlot.Core don't specify >= 2.1.0, but rater 2.1.*. That way they'd automatically pick up potential bug fix versions but nuget won't try to restore them using OxyPlot.Core 3.0.0 which might be released in the future.

[VisualMelon]

@Jonarw @objorke today might as well be preview1 day. Any last-minute blocking concerns?

Things to do:

• [x] Create branch release/v2.1.0-Preview1
  • [x] update format changelog
• [x] Finalise the release notes
  • [x] need to make it clearer that 2.1 is not a drop-in replacement for 2.0, and that updating is in no way essential unless you want to target the new platforms or want the new features)
  • [ ] is anything important missing?
  • [ ] is there enough information there about 'porting'?
• [x] Push everything to NuGet
• [ ] Make a post somewhere with the release notes

Once that's done, I'll try to sort out the same for oxyplot-contrib. If everything goes smoothly enough, my next focus will be on bring oxyplot-avalonia up to Preview1.

[VisualMelon]

Provisional update to the change log: https://github.com/VisualMelon/oxyplot/tree/release/v2.1.0-Preview1

I propose we merge the changes in develop, and create a new branch release/v2.1.0-Preview1. Fixes for 2.1 will be pushed to both branches, and included in the [2.1-Preview1] section of the changelog. Other fixes will be placed in a new unreleased block as usual. When it is time to release 2.1.0 proper or 2.1.0-Preview2, we rename the [2.1-Preview] section accordingly (from the develop and the preview branch) and push it to a new release/2.1.0etc. branch. That way, we have a branch for every release, 'forget' about previous previews in the change-log.

Comments very welcome: I'm a tad nervous about managing branches in the oxyplot repo.

[Jonarw]

Sorry, I kind of missed your post previously. The release notes look good to me! All the important information are there I think.

The changelog also looks fine to me.

From my side we can go ahead with the v2.1-Preview1 release as you proposed. I'll be a bit busy the next days, but I'll try and keep an eye on this thread in case you have any concerns you would like to discuss. But from my side you can go ahead @VisualMelon.

[VisualMelon]

@Jonarw thanks. I guess I should stop fretting about the branches so much; we can always change them later. I'll probably do it tomorrow now when I'm more awake (also, v2 was released on October 19th, so that's a good excuse).

[VisualMelon]

@objorke @Jonarw all packages have been pushed. Is there somewhere sensible to post the release notes, or would it be worth just creating a wiki entry?

[objorke]

Can the release notes be included in a release "v2.1.0" on https://github.com/oxyplot/oxyplot/releases?

[objorke]

Great work! I really appreciate your efforts. Thanks for pushing this project forward!!

[Jonarw]

Thanks @VisualMelon! In addition maybe also the announcement section on the oxyplot.github.io page would be a good place for the release notes? If I'm not mistaken this would have to go in here.

[VisualMelon]

@objorke @Jonarw after far too long, I'm keen to finally release 2.1 as non-pre-release. I've been seeing more and more requests for releases lately (having died down after the preview release) including requests for 2.1 support in non-core platforms (Gtk/Avalonia), while we've had no reports of issues with the preview recently.

The plan was always to cherry-pick only bug-fixes, but I'm tempted to suggest we submit the current branch for 2.1 for simplicities sake as there are only two significant additions/changes which don't present serious compatibility concerns:

• #1746 Addition of ExtrapolationLineSeries which is stand-alone and fairly niche
• #1736 Adds more control over trackers

Apart from that, we have a couple of new (small) bug fixes, and various fixes/additions dealing with problems in the 2.1 preview.

If we had more time to work on stuff at the moment I'd suggest making this Preview-2, but I if there are no objections I suggest we expediate the 2.1 release so that the main goal of making the Skia provision available can be checked off and I can go back to working on insane refactorings when I have time to spare instead of feeling guilting about not shipping 2.1. I'll try to sort out a PR (updating the changelog) and update the release notes soon.

(Note to self: make the issue references clickable in the release notes) (Must update documentation for OxyPlot WPF/XAML as well)

[Jonarw]

Sounds all good to me! Thanks for taking care of this!

[objorke]

Agree, sounds great! Good work!!

[VisualMelon]

Packages have been pushed to NuGet, almost a year later than intended.

Things still to do:

• put release notes somewhere
• update docs regarding Wpf/XAML
• update all the satellite packages

We should also discuss how we want to manage releases going forward. Do we want more bug-fix releases? (I.e. cherry-picking bug fixes onto the release/2.1.0 branch so that we can make them available more quickly timescale?)

(I also suspect we will want to update the Skia and maybe ImageSharp package references soon)

[raffaeler]

I probably missed the most important point. Since the Plot component has been moved to Contrib, but the Contrib is not on nuget, how I am supposed to migrate Plot to PlotView? I landed on Plot because I need to bind the points to an observable collection and I don't see how to do that in PlotView.

[VisualMelon]

@raffaeler the answer is to use the contrib (https://github.com/oxyplot/oxyplot-contrib) packages on nuget; however, as you note, I haven't got around to sorting them out yet. They are one of the many sets of 'satellite' packages.

@Jonarw @objorke are we happy to release the contrib stuff as a 2.1 package in its current state?

(Pushed to my test feed just now: https://www.myget.org/feed/melonoxyplottesting/package/nuget/OxyPlot.Contrib.Wpf )

[raffaeler]

Thank you @VisualMelon I just find weird that binding to a point collection is only possible using a Contrib component and not the "main" one.

[VisualMelon]

@raffaeler you can see the rationale in #1399