Deprecated warnings for feature/netsocket/cellular

[jarvte]

Description

Deprecated warnings for feature/netsocket/cellular. Moved APN_db.h under features/cellular/easy_cellular/.

Pull request type

• Fix
• Refactor
• New target
• Feature
• Breaking change

[0xc0170]

We have MBED_DEPRECATED , this will come later (when?) ?

[kjbracey]

So you're not deprecating it yet, this is just a pre-warning? Not sure how useful that is - if you have the replacement ready, deprecate it now. If you haven't, not much point with the prewarning, although maybe you could point at a feature branch or something. Is the intent that the actual deprecation happens in 5.9, or in a 5.8.y patch?

I think you need to be more specific on what you're deprecating in favour of, rather than just pointing at a directory. Eg if writing a driver derived from PPPCellularInterface or UARTCellularInterface, they should be deriving from AT_CellularDevice etc instead.

If as an app they were using them directly as "generic" they should doing what? There's no direct equivalent - something providing "CellularBase" on an arbitrary FileHandle or set of pins. Does AT_CellularDevice work directly without inheritance - would that give a generic base driver with new API? Could EasyCellularConnection have extra constructors taking specific pins or a FileHandle, so it could be a direct substitute?

For OnboardModemInterface as an app, I guess the replacement is yet to come - it will be CellularBase::get_default_instance() or NetworkInterface::get_default_Instance() in 5.9 if #6108 happens.

Why move the APN database? It's a general utility - if it's not provided by the main framework and you're expecting apps to do APN lookup themselves if not using the easy wrapper, which I understood to be the case, it should remain in a utility position so they can get at it. The easy wrapper and PPPCellularInterface are a couple of potential users, not the only ones.

[AnttiKauppila]

Hi @kjbracey-arm, we cannot decide when this can be deprecated; It is Mbed Os decision.
We want to put this text here for guiding developers not to use these files anymore as the support for those have ended. As I have understood deprecation might happen when Mbed OS 6.0 is introduced, but it might as well not happen.

I agree that commenting should be more specific for developer to easier find a replacement.

IMHO APN database should not be next to deprecated classes because developers might think it will be deprecated as well.

[kjbracey]

Deprecation marker would presumably go into 5.x.y; 6.0 is when stuff marked as deprecated in 5.x.y could actually be deleted.

I would suggest putting actual real MBED_DEPRECATED markers into master ready for release in 5.9 - gives us time to adjust anything to have concrete answers for what the direct replacement is (and by which time we know any kinks in this first 5.8 iteration will have been worked out).

If that's planned, these pre-warnings might be worthwhile to do first for a patch release.

If you want the APN database next to the new code, then features/cellular/utils or features/cellular/framework/utils would be fine.

[0xc0170]

Looks like a bad rebase , as some commits here are duplicates? please review

[0xc0170]

I would suggest putting actual real MBED_DEPRECATED markers into master ready for release in 5.9 - gives us time to adjust anything to have concrete answers for what the direct replacement is (and by which time we know any kinks in this first 5.8 iteration will have been worked out).

If that's planned, these pre-warnings might be worthwhile to do first for a patch release.

@AnttiKauppila Is this correct, MBED_DEPRECATED intentionally not used here, will come later?

[AnttiKauppila]

We have agreed to use MBED_DEPRECATED. We will update this

[AnttiKauppila]

Actually used MBED_DEPRECATED_SINCE as we plan to drop support in Mbed-OS 5.9.

[jarvte]

ARM internal ref: IOTCELL-544

[cmonr]

/morph build

[mbed-ci]

Build : FAILURE

Build number : 1450
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/6264/

[cmonr]

Will relaunch when able to. ARM license CI issue.

[cmonr]

/morph build

[mbed-ci]

Build : SUCCESS

Build number : 1458
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/6264/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build
/morph mbed2-build

[mbed-ci]

Test : SUCCESS

Build number : 1225
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/6264/1225

[mbed-ci]

Exporter Build : FAILURE

Build number : 1099
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/6264/

[cmonr]

CI issue: ARM network licenses could not be checked out during build.

Restarting.
/morph export-build

[mbed-ci]

Exporter Build : SUCCESS

Build number : 1106
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/6264/