[ptx] Re: [PanoTools-devel] branching libpano

[Max Lyons]

> Either way, I propose creating a CVS branch for the 
> backwards-compatible pano12 and changing the files in the trunk so 
> the library is built as pano.dll, libpano.so etc...
> 
> Though I'd like to hear from people who use the library first as 
> they need to make changes too, Max, Pablo, any comments?  (Pablo is 
> away at the moment).

I have mixed feelings about this.  When I put on my Pano Tools developer hat, 
it feels like the right thing to do.  We don't want to be constrained in the 
development by maintaining compatibility with a bunch of binaries for which we 
don't have source code.

But, when I put on my PTAssembler hat, I'm not so excitied about the idea.  I'm 
envisioning distributing two versions of the DLL (one for PTStitcher users and 
one for PTMender, PTOptimizer), reworking PTAssembler and its associated 
documentation.  I fear a barrage of confused e-mails from users (most of whom 
don't have the technical sophistication of the folks on this list) when they 
find themselves in "DLL hell"!  As much as I'd like, I don't have control over 
end-users' machines, and they frequently end up with weird combinations of out-
dated versions of files, copies of a DLL in seventeen different folders and so 
on...I fear that this will add to the confusion.

But, as I indicated earlier, I'm happy to follow the majority decision.  it 
sounds like branching seems to be the popular vote so far, although it isn't 
clear to me if all the relevant stakeholders have commented.

Also how do we enforce that fixes made in one branch get made in the other 
branch as well?  In an ideal world, I know that all contributers would make 
changes in both branches when appropriate.  In practice, I fear that this may 
not happen.  Is there a "merge czar" or someone else who will make this happen? 


Max