The Graph Council should delegate responsibility for specification of the protocol-supported version of Graph Node to the Graph Node development team.
Motivation
This GIP seeks to simplify the release process, and reduce bureaucracy, in order to reduce the time it takes for new features and fixes to be supported on the network by indexers.
Prior Art
Currently, as specified in GIP-0008, the Graph Council ratifies each Graph Node version via a GGP.
High-Level Description
The Graph Council should delegate responsibility for specification of the protocol-supported version of Graph Node to the Graph Node core development team. The Graph Council can revoke this delegation of responsibility at any time.
The Graph Node team should provide the Council and community with updates on new versions, along with any salient information regarding functionality or testing.
The Graph Council will still be responsible for specification of the rest of the feature support matrix, via GGP.
The approval process through the council is currently taking longer than I think it should and it’s not clear if they are really adding any value to the approval process?
Streamlining the Graph Node release profile is a worthwhile idea.
How does this GIP propose defining the objective source of truth for what the canoncial Graph Node version is as of a given Ethereum block?
Part of the intention of the status quo process was so that in the event of on-chain disputes involving Graph Node, there would be an objective reference as to what the canonical indexing and querying functionality should be at any given point in time to resolve disputes.
In the view of this proposal, would Github releases + timestamps be the source of truth and be correlated to Ethereum block numbers in the event of disputes? Or would there be some more explicit process (i.e., signing a snapshot vote) by which the Graph Node developers, with their delegated authority, ratify the new version as of a specific Ethereum block?
That is a good point of clarification - this proposal would retain the Feature Support Matrix as the source of truth, based on that document’s commit history.
The change in documentation structure related to the release of the L2 protocol removed the block specification in the feature support matrix (I think unintentionally, but perhaps also related to Council signing delays). I think for the purpose of version specification, correlation with the commit history is sufficient, but the tighter release loop could also enable the Graph Node team to bring back block-number specification.