Re: [h5md-user] H5MD 1.1 roadmap

[Pierre de Buyl]

Hi Felix,

(I am top replying because I am forced to use a XXXXX wifi access point that 
restricts
proper internet access and blocks all kinds of tunnels I have tried).

For the propositions, I think that this list is the way to go. Create a thread 
with the
proposal number in the subject. I was also thinking of github pull requests but 
they
cannot be archived properly. If you do it this way, the person who closes the 
pull
request could just copy the discussion in a message here.

________________________________________
From: address@hidden address@hidden on behalf of Felix Höfling address@hidden
Sent: Monday, January 12, 2015 11:01 AM
To: address@hidden
Subject: Re: [h5md-user] H5MD 1.1 roadmap

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