On 3/14/12 1:35 PM, Ted Rolle, Jr. wrote: > This effort simplifies the code, no? This is _always_ a good idea. > > Can V1 be deprecated? Maintaing backward compatibility can make the > code more (unnecessarily?) complex.
Eventually, yeah, once everyone has upgraded their nodes and introducers, we can delete the V1 support. I tried to keep the backwards-compatibility code fairly segregated, so it won't be too hard to rip it out. E.g. when the introducer recognizes an old client, it wraps it in a "v2-to-v1-adapter" instance and subscribes *that* instead. When we remove V1, we just delete the adapter code and the old method that sets it up. > 'setup.py build': Where? Don't we already do this when building > Tahoe-LAFS? Yeah, when you download a new tarball and build from scratch. If you have a darcs/git checkout and upgrade, you can usually get away without doing an extra 'setup.py build' step, but not after dependency changes like this one. > When will we be able to safely use the new code? Define "safe" :). I'd suggest starting to play with it next week, after I get a chance to do some more tests over the weekend. If you encounter problems, it should be pretty easy to just roll back to the old version until we resolve them. cheers, -Brian _______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
