>Yes I'm fine with the code. The only thing that makes me think if it's
>worth keep compatibility with not-current x264 versions.
>It's hard to make a general statement about that. My gut feeling is that
>doing like that is fine in branches (e.g. 1.1.x, 1.0.x) not in HEAD.
>Anyway, I've no problem with this patch and I will keep that way
As a rule, my approach for this sort of thing is:
- For releases (1.0.x, 1.1.x), maintain compatibility with anything that
was supported for the .0 release.
- For HEAD, generally support only the latest version, but keep support
for anything that a typical up-to-date system would have. This is why
I left in x264 version 64 support--I'm not sure everybody's up to
version 65 yet, since I'm not sure exactly when it changed from 64.
>PS: just for curiosity: what do you think about switching to SVN
>somewhere into the far future?
I feel like you read my mind. (: I was thinking about the same sort of
thing, but wasn't sure whether it was worth bringing up yet. I was also
thinking of suggesting Mercurial, a distributed RCS, instead of
Subversion--I've been using Mercurial for about half a year now on a
personal project that's a bit larger than transcode, and it seems to be
working fine. Mercurial has the advantage of being lightweight, but the
thing I really like about Mercurial is being able to work with the
repository, especially commit things, while offline. You do have to
learn to deal with revision numbers varying by repository, but I don't
think we're making much use of CVS version numbers as it is, so I doubt
that'd be much of a problem.
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
