Closed davidiw closed 3 years ago
DIP-1 is already in Final stage. Please note partners have implemented or in the process of implementing DIP-1 as it stands today. Changing the Spec which is already final can not only create confusion but may introduce compatibility issues in production. Would the right process be to start new DIP and then deprecate DIP-1?
DIP-1 is already in Final stage. Please note partners have implemented or in the process of implementing DIP-1 as it stands today. Changing the Spec which is already final can not only create confusion but may introduce compatibility issues in production. Would the right process be to start new DIP and then deprecate DIP-1?
What makes you feel like this is an incompatible update to the dip? It's largely improving the readability and improving the organization. If it breaks anything or creates any incompatibilities, then the update has failed it's purpose.
With respect to a new dip, the intent here being a forward compatible update, we've agreed to using versioning. If we were to introduce a completely different off chain format, say ethereum whisper, it would be a different dip.
While I do appreciate that incompatible updates to a protocol are not as disruptive, I think this DIP has gone substantive changes over time and we should be following the process of DIP deprecation rather than updating it. Also as this is an optional standard, it makes sense to keep it in a draft stage until we have sufficient confidence to more to Accepted/Final (this would avoid multiple DIP deprecation/updates).
From https://dip.diem.com/overview Deprecated – The DIP Manager or Maintainers may mark a DIP Deprecated if it is superseded by a later proposal or otherwise becomes irrelevant. Final – The Final state of a DIP means the necessary implementations of the DIP are complete and deployed to the codebase. This DIP represents the current state-of-the-art. A Final DIP should only be updated to correct errata. (edited).
I think this highlights a few issues with the DIP process as a whole. Specifically that DIPs cannot be looked at as a cohesive Specification. In particular it might be more ideal to have a single offchain Specification (that includes everything) and instead use the DIP process as a way to propose and ratify changes to said specification.
At this point, the plan is to take this content and leverage it in a spec instead of updating the DIP. Once the spec is fully written, we should eliminate referring to DIPs from our nomenclature and instead refer to the spec.
Action items: