Release version 1.0

[meggart]

I think the interface to this package has reached a certain level maturity and I am wondering if it would be time to release v1 to indicate this to possible implementers? Are there any ideas for future breaking changes that would need to happen before we do so?

Defining the DIskArrays public API:

The following names should be either exported or marked public:

• ChunkVector
• RegularChunks
• IrregularChunks
• GridChunks
• readblock!
• writeblock!
• haschunks
• eachchunk
• Chunked
• SubRangres
• ChunkRead
• CanStepRange
• NoStepRange
• AbstractDiskArray
• all macros that implement diskarray behavior

[rafaqz]

Possibly some if CommonDataModel.jl implements the interface

[felixcremer]

For a 1.0 we need to define the api surface. We should use the public keyword for the symbols we don't export

[felixcremer]

At least ChunkVector, RegularChunks, IrregularChunks, GridChunks should be exported or marked as public.

[felixcremer]

readblock! and writeblock! should be marked as public.

[felixcremer]

We should export the functions that a user would need to explore the chunking structure of a data set and mark as public all functions and types which are necessary to define the interface for a new data format.

[rafaqz]

haschunks, eachunk, and the objects that can go inside Chunked

[lupemba]

It could be interesting to revisit this now that CommonDataModel uses DiskArray in the interface.

If we at some point want release some of the packages as version 1.0 it might be good to handle DiskArrays first. I think we need a stable DiskArrays.AbstractDiskArray to have a stable CommonDataModel.AbstractVariable so we can then have a stable NCDatasets.NCDataset or others.

[rafaqz]

We should remove the macro interface before 1.0 since CommonDataModel doesn't need it anymore, and in a few edge cases its pretty broken.