El mié, 16-07-2008 a las 15:03 -0700, Cassie escribió: > So Paul - you are using the current code in the hi5 stuff and you know how > to make a branch :) > Ya wanna give it a shot? >
Reading a bit late, I might be off base easily Once the branch is done, nothing impedes merges of *big* changes from the trunk back into the branch if something important needs to be backported, though it does not look very practical, as this is supposed to be a "retirement/historical" branch rather than a development or stable one. snvmerge.py looks like the way to go if code needs to be merged or cherrypicked back into the branch. Regards Santiago > .. JsonWireFormatBranch... GadgetDataServletBranch... > 0.8WithoutRestfulSupportBranch > I am coming up with some awesome names... > > - Cassie > > > > On Wed, Jul 16, 2008 at 1:53 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > > > We could call it reTIRED; get rid of TIRED by using REST. > > > > On Wed, Jul 16, 2008 at 1:16 PM, Louis Ryan <[EMAIL PROTECTED]> wrote: > > > > > +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! > > > >> > > > > > > > > > > > > > -- Santiago Gala http://memojo.com/~sgala/blog/
