CIP-0080 | Transaction Serialization Deprecation Cycle

[JaredCorduan]

This CIP proposes a policy for how we manage the backwards compatibility of the binary format for transactions. The summary is:

• We should strive to maintain backwards compatibility (which we've maintained since the Shelley phase began).
• Serious flaws can be fixed immediately (at the next hard fork), and can break backwards compatibility.
• Non-Serious flaws can be fixed (at the next hard fork), but the old format must be supported for at least six months with support ending at the next hard fork event after the six months have passed.

---

(current draft in branch)

[rphair]

thanks @JaredCorduan ... not sure which one of these titles suit better; the "for Compatibility" title would be more familiar to the uninitiated (e.g. me) but all other things being equal it's probably better to have the PR title match the document.

[rphair]

Unless @KtorZ objects this could be a good time to get ahead of the changes to CIP document standards in progress, particularly the header preamble (https://github.com/cardano-foundation/CIPs/blob/cip-cps-rework/CIP-0001/README.md#header-preamble):

[rphair]

There will no longer be a Type: field but instead a Category: (https://github.com/cardano-foundation/CIPs/blob/cip-cps-rework/CIP-0001/README.md#categories) which I would think should be Ledger. But I don't see that on the list of categories, nor do I see a Core category that I thought I read during recent drafts of CIP-0001.

@KtorZ I must have missed something about how CIPs for core features are categorised & why they aren't on the current list of choices; what would we do in this case?

[KtorZ]

I'd urge the respective maintainers of the various areas of the protocol to register an appropriate category for their respective areas. It is obvious that the cardano-ledger wants to engage more with the CIP process; and @JaredCorduan has been a recurring point of contact there; So simply capturing that in a document similar to CIP-0035 would be the way to go.

[JaredCorduan]

#456

[JaredCorduan]

thanks @JaredCorduan ... not sure which one of these titles suit better; the "for Compatibility" title would be more familiar to the uninitiated (e.g. me) but all other things being equal it's probably better to have the PR title match the document.

I'm happy with either, and thanks for keeping it consistent!

[KtorZ]

As discussed in the CIP meeting today, there's no "ledger" category registered yet in the CIP process. Ideally, we would want something similar to CIP-0035: Plutus Core Evolution for all areas of the protocol that engage with the CIP process.

Having said that, this CIP sounds like a good foundation for a "ledger" category -- even though the current document is mainly focused on CDDL format of on-transactions, I imagine it could be extended to define the overall strategy for changes in the ledger and how people can engage with the team on these topics.

[KtorZ]

@Ryun1 @rphair

I am doing some housekeeping today and I believe this CIP was already discussed and could be merged (almost) as-is. Given its informational nature and being pushed by the ledger team itself.

I did resolve the last "cosmetic" issues on the header, folder name and so on.

[rphair]

@KtorZ I agree and I cannot find anything wrong with it & don't think the Ledger team or anyone else are likely to either. I am therefore itching to merge this but guess that you wouldn't have assigned the Last Check label unless SOP is to do this at the meeting (just going to resolve merge conflict for now).

[Ryun1]

@KtorZ @rphair LGTM

[KtorZ]

@rphair I did put the last-check mainly as a reminder in case you guys didn't replied promptly. But I underestimated you both :p

[rphair]

OK, I'd been thinking Last Check had been a flag for a final review at the meeting, but it seems we can merge these if in agreement online. Therefore @KtorZ perhaps also #421 #422 can be merged?