Organization for refactoring about transport layer

I create this issue to organize the team work.

I plan to begin massive refactoring about “adding a way to add more transport Layer” (#1025).

This will be a lot of changes (with lot of API break) and this will probably take much time. I feel this will be a good idea to not work on complex feature at the same time to avoid to manage error prone conflicts.

So my idea would be to deliver a 2.0.0-M7 with all ongoing work :

• timestamped node.
• OSCORE minimal viable feature. (Let me know if there is more than that ?)

Then go for a kind of feature freeze during the transport layer work. I think I will do most of the work in separated branches and integrate this in master once all will be in an acceptable state.

At the same time we can continue to add some bug fix to master (and so keep the sandbox clean to get feedback about 2.0.0-M7). This will also allow to eventually release a 2.0.0-M8 with only small changes/bug fixes.

@Michal-Wadowski, @rikard-sics does it sounds good to you ?

[JaroslawLegierski]

Yes I’m using endpoint_client branch from PR #1323

[rikard-sics]

I tried to investigate on #1257 without success disappointed (#1257 (comment))

Thanks for looking into this. I will take some time to investigate this also, still good to figure out what is going wrong in that scenario.