+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!
