Re: [h5md-user] H5MD 1.1 roadmap

[Pierre de Buyl]

On Tue, Jan 20, 2015 at 10:56:37AM +0100, Konrad Hinsen wrote:
> On 09/01/15 16:36, Pierre de Buyl wrote:
> 
> >"""
> >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
> >"""
> 
> The critical term here is "single codebase", which I think requires
> clarification. Does it mean "without inspecting the file's version number
> for making decisions"?

I think that for all current proposals one does not need to check the j in "i.j"
so that they would fit your extended criterion. It is actually a very nice
update that we should use!

> I'd like to propose another principle, for the process of accepting
> proposals: each proposal must come with (1) at least one working
> implementation and (2) at least one illustrating example file.
> 
> The motivation is not so much to have a useful implementation right away,
> but to be sure that the proposal actually has been implemented. In my
> experience, it is impossible to write down a non-trivial specification
> without developing an implementation in parallel. Moreover, the
> implementation and example can help to clarify points that might be unclear
> in the text.
> 
> Note that I do not propose that the implementation and/or example become
> part of H5MD, only that they should be part of a proposal.

Excellent idea! To be honest, I have the secret plan to implement all the
proposals (maybe not "proposal 102: Storage of charges" because its implications
are trivial) before the deadline I have set just to be sure. As it is "agenda
dependent" I did not dare to commit to it.

For info, I already store "pairs" to know about pairwise bonded interactions.

Pierre