On Thu, 2008-12-11 at 06:25 +0000, Andrew Church wrote: > >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.
That's less or more what I was thinking. Nice to agree such easily ;) > >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 think it's not time, just because we do need 1.1.0 out. But that _will_ happen (in a way or another) before the 2008 ends. After that I think it's time to switch to something more modern than the good old CVS, at very least because every thing that saves a little of developer time it's worth trying. > 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. That's plain perfect! I read a few positive reviews about hg. I got some experience with bazaar-ng (the VCS from canonical guys) and while I do really enjoy the concept of distributed VCS, I had some eyebrowing experience using bazaar, like losing the full repo history (It got corrupted) after doing nothing so strange. Well, I don't consider doing a raw backup using tarball and restoring it something strange, but maybe it's just me. That other nice thing about hg is that berlios.de offers hg hosting :) berlios.de already hosts tcforge.berlios.de (the support site featuring news, download site and a collection of transcode-releated side projects of mine.) So, a tentative plan is to put out 1.1.0 before the year ends, then move to mercurial during January. +++ While we're on topic, what do you think about moving enterely to berlios.de ? I chosen that site because I want(ed?) to unify issue tracker, VCS and news site previously scattered into fromani.exit1.org, cvs.exit1.org and tcfoundry.hostme.it[1] into just one site, without asking Joern for more services. Berlios seemed the best overall compromise, but I'm open to alternatives (of course tcforge.de will stay as it is, in the worst case scenario it will be reduced to my own playground :)) +++ [1] this will phased out during the beginning of 2009 because the hosting grant I got is expiring. Bests, -- Francesco Romani // Ikitt http://fromani.exit1.org ::: transcode homepage http://tcforge.berlios.de ::: transcode experimental forge
