Clearly mention the implementation phase or grace period for ZEP proposals

[MSanKeys963]

Hi all. 👋🏻

Since ZEP0001 got accepted, there have been questions regarding the changes introduced to the V3 spec after the voting phase ended. They are:

• Rename endian codec to bytes zarr-specs#263 (comment)
• ZEP0001 status clarification, not "Final"? zarr-specs#265

There's a clear need to mention the implementation phase/grace period in the ZEP0000 document.

Please let me know your thoughts. Thanks!

CC: @zarr-developers/implementation-council @zarr-developers/steering-council

[mkitti]

This stage definitely should be clarified. Also the conditions for voting again should be made clear.

[rabernat]

My $0.02 is that the process we have set up doesn't really make sense. It requires everyone to vote on the final spec or ZEP before anyone actually starts implementing it. Instead, we should be implementing along the way and using what we learn to revise the proposed spec. In fact that is what is happening now. A spec should only become "final" once it has been vetted extensively via implementations and battle tested in production. We are very long way from that with V3 still.

This is okay. We are learning how to do this sort of community-driven spec evolution. We should not feel any need to stick to the ZEP process as we defined it. We just came up with it out of thin air, and there is no reason to expect it would just work without some tweaks and iteration.

In the meantime, we should extend the "grace period" to recognize the reality that the spec will not be done until it has been thoroughly updated.

[mkitti]

I may be conflating a few distinct concepts, but I do think we need to make some kind of stable "release" for others to build upon.

It's OK to iterate on the specification, but that should be reflected in the versioning. If breaking changes are needed later, then we should release Zarr v4.

The HDF5 library uses an odd/even development release cadence where odd valued minor versions (1.13) are unstable development releases while even valued minor versions are stable releases.

I do not use the odd HDF5 minor releaes unless I'm trying to add a new feature. This just reflects my current tolerances for instability in that space.

My understanding is that we have at least two full implementations of ZEP0001. As soon as those implementations are stable and interoperable that should be Zarr v3.0.0 and follow semantic versioining.

Does "Final" mean that's when we release v3.0.0 or does it mean when we are done with the v3 branch and are now moving into v4?

I really would like to see some kind of signal that the foundation of Zarr v3 will stop changing so people can start building upon it.

[rabernat]

I really would like to see some kind of signal that the foundation of Zarr v3 will stop changing so people can start building upon it.

I agree that we should be building towards a stable release. Semver would be useful. The challenge is that, until people start implementing it, we won't know if the spec is really right. The ZEP process as we defined it is more of a waterfall style. By putting the spec "vote" before the implementations, we have skipped the very useful iterative process that comes between spec and implementation. In retrospect, I wish we had froxen 2.0 and then started evolving incrementally towards 3.0, via 2.1, 2.2, etc etc, implementing all the tiny changes as we go.

An example of a community that does this right is is STAC.

My understanding is that we have at least two full implementations of ZEP0001. As soon as those implementations are stable and interoperable that should be Zarr v3.0.0 and follow semantic versioining.

This would be a nice target. My feeling is that there has been a lot of noise recently from implementers who are finding issues as they attempt to implement the spec as is. We should have a way to incorporate this feedback.

I really would like to see some kind of signal that the foundation of Zarr v3 will stop changing so people can start building upon it.

Me too. But do you think the spec is good enough today to send that signal?

[joshmoore]

A few, at this point slightly stale, thoughts:

• Definitely agree that we need some mechanism to allow an incremental increase in the trust that implementers have (I keep making the comparison to simulated annealing 😄) and could get behind alternating versions (I had completely forgotten that)
• In my experience semantic versioning of a data format is tricky at best. The amount of legacy that quickly accumulates comes difficult to work with. At least it should be very well-defined what types of changes are permissible for minor and patch bumps.
• As I've mentioned on the ZEP calls and a few other places, my preferred improvement on the current would be to move to a system of ... "endorsements"? "roll calls"? or "iterative votes"? if you want ... which allow those who are on board to express it early and help to get others on board. i.e., a single late vote was definitely problematic, but from the organizational side, having clear points in time where we are asking for the feedback helps tremendously in not letting any voices being overheard.