Re: [h5md-user] H5MD 1.1 roadmap

[Felix Höfling]

Hi Pierre,

Thanks a lot for taking action and pushing H5MD forward! It's one year now  
since release 1.0 and it's time to collect what we've discussed since.

I'm currently pretty busy with finalising some long-term projects and  
that's why there was so much silence from my side. Be assured that I'm  
still very much interested in developing H5MD. At least, I'll try to send  
a few comments.

Am 09.01.2015, 16:36 Uhr, schrieb Pierre de Buyl  
<address@hidden>:

> Hi all,
>
> I think that it is time for a H5MD 1.1 roadmap
>
> In the absence of further comments on this versioning issue, I propose  
> to follow
> http://thread.gmane.org/gmane.science.simulation.h5md.user/670/focus=691
>
> """
> We could use the following principle: As long as it is possible for a  
> H5MD i.j+1
> reader to read a H5MD i.j file unambiguously and in a single codebase,  
> we may
> use i.j+1 for the update. Else, the version jumps to i+1.0
> """
>
> Felix, I think that what this means is actually "Backward compatibility"
> http://www.hdfgroup.org/HDF5/faq/bkfwd-compat.html
>
> """
> Backward compatibility refers to one of the following questions: Can a  
> newer
> (later) library read a file and/or objects within a file that were  
> created or
> written by an older (earlier) library?
> Will an application written to work with a newer (later) version of the  
> HDF5
> Library compile, link, and run as would be expected with an older  
> (earlier)
> version of the library?
> """

I agree with what you've written. Our intention is indeed correctly called  
"backwards compatible".

In any case, we should explain what we have in mind and add a statement to  
"h5md/version". An attempt to translate the second sentence from the HDF5  
guide:

"A reader software written to work with a newer (minor) version of the  
H5MD file format can process files of an older (minor) version of the H5MD  
format, unambiguously and within a single code base."

> Now, for the updates themselves: I propose to adopt:
>
> - Proposal 100: Storage of time information, as it is in the current  
> proposal,
>   using attribute.
> - Proposal 101: Particles and tuples lists
> - Proposal 102: Storage of charges
> - Proposal 103: Connectivity group

Where can we comment on the proposals? Shall we continue old, existing  
threads in the mailing list, or better create a new one with the proposal  
number in the subject?

Where do we discuss/submit bug fixes and patches? Such as the one above  
for the file format versioning? There could be a directory "Patches" or so  
next to "Proposals". Or would you prefer that we create a diff file via  
Git and send it to the mailing list?

> To allow for some time but also bring in these needed updates I propose  
> to leave
> a calendar month from now before applying the updates.

Very good to define a deadline. But please send a reminder 1 week before  
the actual date ...

Best regards,

Felix