Re: Schedule decision

Hi Ed,

> > Hi all,
> >     I've been working on revising groups in HDF5 files (to allow for 
> > creating
> > groups which track creation order, among other things) and its become 
> > obvious
> > to me that my first attempt at implementing the indices required will not be
> > a good long-term solution.  Switching horses midstream could delay getting 
> > the
> > HDF5 1.8.0 beta release by ~6 weeks if I change the indexing implementation
> > right now.  I can, however, continue with the flawed index implementation I
> > currently have and build up to most of the API changes that would be 
> > required
> > and then go back and revise the guts of the library to use a better data
> > structure on disk for storing the indices required.
> >
> >     This would allow outside applications/libraries (like netCDF-4) to 
> > mostly
> > stabilize their code on the new API while I went back and reworked internal
> > things.  This has several trade-offs that I can think of:
> >       A - It gets a [reasonably] stable API to testers somewhat sooner.
> >       B - Its going to take longer, because I'll have to re-do some work.
> >       C - Files created during the "transition period" will _never_ be able 
> > to
> >             be read by any other version of the HDF5 library - they must be
> >             discarded by testers.  
> >
> >     If we've got enough flexibility in our schedules, I would prefer to 
> > avoid
> > doing the re-work and just get things right first.  But, since there is an
> > alternate plan that could work, I thought I would raise the issue.
> >
> >     What does everyone think?
> >         Quincey
> >
> >
> If the files produced by the temporary method of indexing are going to
> be unreadable in the future, that's not a good thing.
    Yes, that's why I brought it up also.  However, its only for a limited time
and we would try to limit access to the development branch of the HDF5 library
during that time.  (As I said above, I'd still prefer to avoid going down this