Informing downstream compilers about sigificant code changes and how to migrate? about p4c HOT 4 CLOSED

Another important point is versioning. Is there any policy here? E.g. LLVM breaks downstream always :) However, dot releases are assumed to be API and ABI compatible, they are for regression fixes only.

from p4c.

We tried to inform and ping downstream users about breaking changes. But the engagement was simply too low and keeping changes back because of an unknown user base was not ultimately not practical. It led to a lot of stagnation.

I do like the Boost approach where they maintain a changelog and tag breaking changes. This way you can quickly identify which changes could cause problems.

We can do this with a label for now. This way we can also retroactively tag breaking changes. We can also introduce an issue template which suggests "Instructions For Breaking Changes" as a header. This way we do not forget to document these changes... :)

Another important point is versioning. Is there any policy here?

We do not have a real version policy yet, we currently only have automated monthly releases and a version pegged to the current version of the P4 specification.

from p4c.

We tried to inform and ping downstream users about breaking changes. But the engagement was simply too low and keeping changes back because of an unknown user base was not ultimately not practical. It led to a lot of stagnation.

Sure, my whole point was to allow for breaking changes, but acknowledge them and make it easier (if possible) to migrate.

We can do this with a label for now. This way we can also retroactively tag breaking changes.

I like that. A label on the PR + description in the PR itself sounds good enough to me. Ideally we would include info in the changelog for each release so people who use releases would see them.

Another important point is versioning. Is there any policy here?

We do not have a real version policy yet, we currently only have automated monthly releases and a version pegged to the current version of the P4 specification.

Personally I have no strong feelings about versioning... we don't use the version when updating our downstream anyway.

from p4c.

I like that. A label on the PR + description in the PR itself sounds good enough to me. Ideally we would include info in the changelog for each release so people who use releases would see them.

I created a PR for this: #4692

from p4c.