Major version update planning
See original GitHub issueIn early 2017 we plan to update to major version 2 of the client libraries. This issue is to track changes we may make that require a major version change.
- Remove support for Silverlight platform.
- Remove support for <.NET4.6
- Remove support for older Windows Phone apps - we will only support Windows 10+ using UWP apps (including native).
- Update all dependencies to the most recent major version - e.g. Newtonsoft.Json, BouncyCastle, …
- Remove RSACryptoProvider from the public API.
- Change the package and project structure of some targets to contain a single dll, rather than two dlls? (or make the entire support library a single dll/package?)
- Add get-range to
IMediaDownloader
- Change the return type from
void
toIProgressDownload
of generated code that usesMediaDownloader.Download(...)
. This is to expose download errors when using sync calls, which at the moment are completely hidden. This will address #803 - Add request/response logging (#746)
- Sort out some timezone issues (#853) (or possibly only accept UTC, and throw otherwise?)
- Revisit all auth mechanisms and make sure the as many as are possible are available on as many platforms as possible.
These decisions are not yet final.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:6
- Comments:33
Top Results From Across the Web
Major Updates and Minor Updates for Business Central ...
Minor updates roll out every month. Get an overview of the release plans at Dynamics 365 and Microsoft Power Platform release plans. For ......
Read more >Software Versioning Best Practices
This method uses three numbers for each software version, in Major.Minor.Patch sequence. When a major, minor, or patch update is made, the corresponding ......
Read more >Don't go making major version changes | by Jakob Perry
Never release a new major version within 9 months of a new major core release without planning to upgrade the last major version...
Read more >Best practices for major version upgrades
Our recommended approach for major version upgrades is to simply make a new deployment with the latest major version, reindex everything, and make...
Read more >Major updates
Major updates are quarterly releases that include one or more or all of the following components – application binaries for bug fixes, new...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
We’ll have a fairly detailed update here by the end of this week (2016-02-24). Sorry for the silence and delay.
Edit 2016-02-23: Apologies, this update is going to be delayed by a week (hopefully no more). So we now expect to post details here by 2016-03-03
We will be remaining in v1.x for the packages in this repo; we will not be producing a v2 release any time soon (if at all). However, we will continue to address as many issues as we can within v1.x releases.
Going through the items listed above:
Additional platform support
We will be starting to investigate UWP (native) and possibly Xamarin support shortly. We don’t have a timeline for when this investigation will be complete, and we don’t guarantee that we’ll end up supporting these platforms, but will add support if feasible.
Remove support for various older platforms
Following on from the pattern we used in the v1.12 release we will remove support for Silverlight, Windows App 8 (UWP predecessor), Windows Phone 8.1, and Windows Phone Silverlight in the support packages (Google.Apis.Core, Google.Apis, Google.Apis.Auth, and Google.Apis.Auth.Mvc) in a future version. Generated API packages will still support all platforms, and will redirect these deprecated platforms to a suitable version of support libraries. In the same way that targeting .NET4.0 today will bring in v1.10 of the support packages.
Update all dependencies to the most recent major version
Removed dependencies:
BouncyCastle
(#880),Log4net
(#890). Remaining dependencies:ZLib.Portable.Signed
: This dependency will be removed once the platform deprecation (above) has been done.Newtonsoft.Json
: We will upgrade our dependency from v7.0.1 to vLatest in a future release.Remove RSACryptoProvider from the public API
We cannot do this (would be a breaking change), so will continue with the current solution.
RSACryptoProvider
is in the public API in the .NET4.5 target.RSA
is in the public API for netstandard, and will be used for all future targeted platforms.Change the package and project structure
We cannot change the package structure - i.e. which public entities are in which DLL - (would be a breaking change), so will continue with the current package/dll structure. This is more of an internal project/build issue than a user issue, so only affects people building and working on the project source.
We will tidy up the project structure in a future PR, and probably move to VS2017/csproj for a targets. The produced packages will still be consumable in earlier/different versions of VS.
Add get-range to
IMediaDownloader
We cannot do this (would be a breaking change), but may add a DownloadRangeAsync (or something similar) to the underlying public MediaDownloader class in a future release.
Change the return type from void to IProgressDownload of generated code that uses MediaDownloader.Download(…)
We cannot do this directly, as it would be a breaking change. However we may add an extra method to do this in a future release.
Add request/response logging
This is done #935
Sort out some timezone issues (#853)
We cannot do this, because it would be a breaking change. We expect to leave this as it is.
Revisit all auth mechanisms to ensure platform support
This is done;
GoogleWebAuthorizationBroker
is now available in netstandard #962, which I think means there is auth mechanism parity between .NET desktop and netstandard.