I think that something as simple as a search-and-replace is fine. Binary incompatibilities that require a clean rebuild are fine too. Even changes that require code to be regenerated, while annoying, are okay, though it would be nice to batch them up, and we should implement some automatic version-checking first.
However, I think that changes that require developers to make nontrivial changes to their applications and actually *think* just because they want to upgrade Thrift should be avoided unless a really solid case can be made for their inclusion. (Either because they provide a really big benefit, or the number of programs that have to be re-thought is relatively small.) I know that, as a new Thrift user, you want to mold everything to fit your expectations, but please have mercy me, who would be responsible for updating dozens of programs at Facebook to work with the new version! --David Bryan Duxbury wrote: > Hey all, > > There are a probably a fair number of sweeping changes that need to > be made now that we're in Apache. One amongst those in particular > that I'm thinking about is the task to convert all the > "com.facebook.thrift" packages in java to "org.apache.thrift". As > David has noted, this would be a breaking change for clients. > > My question is, in general, during this incubation period, should we > be very interested in maintaining backwards compatibility? I know > that there are existing clients and servers written all over the > place, but that will be true at every stage of our development from > this point onward. However, right now, when we are freshly in the > Apache Incubator, before any official Apache release has been made, I > think we have an opportunity to shake things up quite a bit. > Consumers who download the new release, post-Apache move, will have > to be aware that big things have changed. > > What do others think? > > -Bryan >
