Skip to content
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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify that zarr layout given in spec is an example #277

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 10 additions & 1 deletion 0.5/index.bs
Original file line number Diff line number Diff line change
Expand Up @@ -65,7 +65,7 @@ like S3 or GCS.
Images {#image-layout}
----------------------

The following layout describes the expected Zarr hierarchy for images with
The following layout shows an example valid Zarr hierarchy for images with
multiple levels of resolutions and optionally associated labels.
Note that the number of dimensions is variable between 2 and 5 and that axis names are arbitrary, see [[#multiscale-md]] for details.

Expand Down Expand Up @@ -652,6 +652,15 @@ Version History {#history}
</tr>
</table>

Changelog {#changelog}
======================

Version 0.6
Copy link
Member

@joshmoore joshmoore Nov 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean 0.6 here? If so, I understand this to be a collection of more fine-grained changes between versions. If so, can we move it to the top-level? This could lead to confusion as to the state of "0.6" if in the 0.5 spec which could lead to confusion.

But maybe you meant this is part of 0.5? Sorry. A bit confused.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So in my head 0.5 is released and therefore fixed, because it is not versioned at a more granular level (e.g., 0.5.0, 0.5.1, 0.5.2). See my reasoning for why I think 0.x should be fixed on release in #278 (comment).

If so, can we move it to the top-level?

I don't see the harm (and I think it makes it easier to understand) in calling out which version a change happened in (and coversely, what list of changes happened in a given version)

This all ties back to #276 it seems - shouldn't there be an "active development" version of the spec, which changes are made against, which will become the version after the most recent versioned release?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm.... to be clear: did you edit in /latest/ or in /0.5/? @normanrz's PR may have moved your target.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Latest is currently symlinked to /0.5/: 72c4430, so I don't think there is a latest copy at the moment?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope. That was what I was trying to figure out. If you had made your change on /latest/ then @normanrz's change automagically integrated it.

-----------

- Clarified that the example file layout given in section 2.1 is
an example of a valid layout, and not *the* expected layout.


<pre class="biblio">
{
Expand Down
Loading