-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clearly mention the implementation phase or grace period for ZEP proposals #52
Comments
This stage definitely should be clarified. Also the conditions for voting again should be made clear. |
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. |
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. |
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.
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.
Me too. But do you think the spec is good enough today to send that signal? |
A few, at this point slightly stale, thoughts:
|
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:
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
The text was updated successfully, but these errors were encountered: