[annodex-dev] libannodex and pyannodex versioning.

[Conrad Parker]

On 19/06/07, Ben Leslie <benno at benno.id.au> wrote:
> So, I got this email the other day castigating me for having version
> numbers of pyannodex running into the 4 digits. Now it turns out this
> is mostly because I'm just using one digit for pyannodex that hangs
> off the end of libannodex.
>
> I'm currently thinking of ways this could be better.
>
> 1/ Integrate pyannodex into libannodex, so my patches are just
> patches on the main source, and then we only have 3 digits of
> version.
>
> 2/ Come up with my own independant numbering scheme.

I think this is the best option. That way you can make or break a
pythonic api regardless of what changes underneath in libannodex, and
without feeling any particular need to directly wrap un-pythonic C
functions.

>
> 3/ Everything is fine, leave it the way it is.
>
> Any comments would be helpful.
>
> Along the same lines, is there a 1.0 planned? What features
> are missing? Can We just make 0.7 == 1.0? (Especially since
> there haven't been any releases for a good year now).

Nah, lots of libannodex is hacky, buggy, broken and putrid. I'd like
to at least fix the broken and buggy bits before calling it 1.0, then
perhaps make a simpler (perhaps API compatible) version that doesn't
carry all the historical and irrelevent crud that's now in libannodex
(which has bloated through 3 different versions of annodex specs).

In particular, the only bit that's really usefully left in libannodex
is the muxing and time-offset generation -- the reading part has
mostly been migrated to liboggz (which is where the development effort
has been the last year or so).

As for time-frame, now that we're pretty heavily testing liboggplay,
libannodex (via cmmlwiki and pyannodex) is getting a good beating. For
my part, I'm pretty much done with major changes currently required to
liboggz and libfishsound atm (towards liboggplay) so I'll be turning
my attention to libannodex RSN.

cheers,

kfish.