Eliminate pkg directory

[stv0g]

We are no using a pkg/ subdirectory in Pion repos.

We should remove it. Unfortunately, this will break API compatability.

[Sean-Der]

@stv0g is it possible to do with a type alias?

Agree it would be nice to have everything in pkg!

[stv0g]

I think this was a misunderstanding. I am # proposing to absolute the pkg directory. We could use type aliases and deprecated them. This would move most of the code outside auf the pkg dir. But it would still be around for some time until we fully remove it..

[aler9]

pion/rtp has been blocked since a year due to the fact that transition to /v2 is frozen due to compatibility issues with dependent libraries. This prevents security fixes from reaching users and is becoming a key issue.

Since transition to /v2 can't happen right now, a solution consists in downgrading to /v1 and replacing breaking changes with soft updates, marking old objects with a deprecation notice.

@stv0g if you like the idea, we can arrange to:

1. transfer master branch into v2 branch
2. transfer v1 branch into master branch
3. perform the deprecation work, starting from the pkg folder.

[aler9]

BTW, i have tons of material to contribute with respect to packetizers and depacketizers, since i'd like to move as much code as possible from gortsplib to this library, but i can't do it until the library is stalled.

[stv0g]

Hi @aler9,

I fully agree with your statement. We should resolve this state asap.

I used go-apidiff to check for the current API breaking differences between v1 and v2:

stv0g@ubuntu:~/workspace/pion/rtp$ go-apidiff --print-compatible defa1718fec1d5a74b53a57c34c313a3c5eba3f5 HEAD

github.com/pion/rtp
  Incompatible changes:
  - NewPacketizer: changed from func(uint16, uint8, uint32, Payloader, Sequencer, uint32) Packetizer to func(uint16, uint8, uint32, Payloader, Sequencer) Packetizer

Is this really everything which changed?

I am not a big fan of downgrading, as this will only postpone the issue. We will have always issues when we want to release a new major version at some point in time. Shouldn't we rather focus on fixing the API and release a v3?

[aler9]

Is this really everything which changed?

There's also #119

I am not a big fan of downgrading, as this will only postpone the issue. We will have always issues when we want to release a new major version at some point in time. Shouldn't we rather focus on fixing the API and release a v3?

i perfectly agree with you but the fact is that i'm not the owner of the project and there's a portion of the community that stands with what @jech said in pion/rtcp#127:

This would seem to imply that it is impossible to bump the version of rtcp without simultaneously bumping the version of webrtc, which you've stated you're not ready to do now. (It would of course be possible to define v2.Packet as a type alias of Packet, but that in turn would prevent us from changing the Packet structure, which might or might not be okay.)

bumping pion/rtp or pion/rtcp is not possible without bumping pion/webrtc. But the question here is not about introducing new features, but performing maintenance on the existing ones.

[stv0g]

Okay, lets go with the downgrade approach then. Maybe we can factor out the v2 API breaking changes into a new PR which we can merge lateron?

[Sean-Der]

@stv0g 100% agree, thank for fixing this @aler9

I don’t see the benefit of starting a new major version unless we can give users a significant benefit