+1 on retiring. Anyone still using that code care to suggest a name as it will likely be most relevant to them.
On Wed, Jul 16, 2008 at 1:06 PM, Chris Chabot <[EMAIL PROTECTED]> wrote: > +1 on retiring the old GadgetDataServlet code. > > It's been a pain in the backside to see features being added to one > back-end or the other, and it was confusing contributers too; My fingers > have been itching to be able to make that move, but the java situation meant > we needed to wait a bit longer before we could do that because it seemed > better to time it together w the java version. > > In essence doing a mini release or telling people to use revision XXXXX is > the same really, just a snapshot in time; But without being able to fix > things like you could on a branch... so branching has my vote. > > This will put some strain on people who are developing using the latest > version of shindig, but that chose to stick to the old wire format for now > (i know of a few of those) but i guess they need to switch over at some > point anyhow to get 0.8 support, so what better time then the present right? > :) > > How's other committers feeling about this? As far as i'm concerned sooner > is better then later :) > > -- Chris > > > On Jul 16, 2008, at 7:59 PM, Cassie wrote: > > Now that we've decided on a path for the restful java code it's time to >> figure out how we are going to deprecate the non-rest old code. (ie >> GadgetDataServlet and friends). I know people are using the old code in >> prod >> so it needs to live somewhere and I'm not sure what the proper thing to do >> in svn is. >> >> - do we branch in svn and put the old code on the branch? (i think the new >> rest code should definitely be in "main") >> - do we just tell people to stay at revision xxx if they want it? >> - do we do a mini-release? >> >> It is probably something else I haven't thought of at all. And php guys - >> you will probably have to do this too, so we should probably share the >> same >> decision. >> Thanks again for all feedback. >> >> - Cassie >> >> ps - just think, we almost have a clean social-api codebase! >> > >
