transcode-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Original]

Re: [transcode-users] transcode version (was: transcode-0.6.13released)


To: transcode-users@xxxxxxxxx
Subject: Re: [transcode-users] transcode version (was: transcode-0.6.13released)
From: Jörn Reder <joern@xxxxxx>
Date: Sun, 31 Oct 2004 23:28:18 +0100
Delivered-to: itdp@localhost
In-reply-to: <20041031212311.GC2654@funk.gsky.dom>

Jacob Meuser wrote:

> further, transcode is an end program.  it doesn't have libraries
> that other programs use.  there's really no need to differentiate
> compatability by versions.

Ups, I'm contradictory here ;) transcode is not just a frontend. Yes, 
there are no transcode libraries other C programs are linked against, 
but there are a lot of frontends, which use transcode as a backend (e.g.
dvd::rip, but also tons of shell scripts dozing in many home 
directories... ;).

So compatability *is* an issue. Not on internals like C symbols, but on
all command line interfaces, options, general behaviour and stuff. E.g.
the (very reasonable) change from RGB to YUV as the default colorspace 
broke dvd::rip's preview grabbing. No big deal, I would even accept 
calling this a dvd::rip bug ;) - but nevertheless it's a good example.

On the other hand the tcdecode segfault in 0.6.13 is a critical bug 
breaking dvd::rip and other DVD related applications completely, and I 
hope this will be fixed by a quick maintanance release, otherwise all 
transcode binary package maintainers need to pick up the patch, and 
users who compile it on their own need to check online resources, 
whether there are new patches available. This may result in many 
different transcode packages with different patch sets applied: probably
very confusing, e.g. when it comes to bug reporting and the user want's
to define the exact version of "his" transcode...

> anyway, I plan on making the critical patches to the latest release
> available, somewhere, and putting out a new release about every
> three months.

Hmm, is it too hard to maintain a little CVS branch with these patches 
applied? In particular, when no "big changes" are made on HEAD, and only
small patches are committed to the branch, CVS makes it easy to merge 
the patches back to the main trunk. After all I believe that this is 
less effort, than managing these critical patches by hand.

Just my 2c.

Regards,

Joern

-- 
$a=$a[8][67][9][0][42][214][82][78][0][50][69][68][69][82][0][73][78][0]
[65][0][20][16][0][68][73][77][69][78][83][73][79][78][65][76][0][65][82
][82][65][89]=sub{sub _($){print$_[@z]}($z,$i)=@x;(++$i)while!$z->[$i];$
s+=$i;_ chr($i+32);$s!=2292&&&$a($z->[$i],$c>>$e)};&$a(\@a,$d<<$f);_"\n"

Attachment: pgp00026.pgp
Description: PGP signature


[Prev in Thread] Current Thread [Next in Thread]