Backwards compatible OB strategies: Delete, save, other?

Apr 7, 2008 at 7:53 PM
Now that we're in the "fit and polish" stage of Unity 1.x development, Scott brought up something last Friday in the team room that I wanted to throw out there for more input.

Right now, the ObjectBuilder2 assembly includes both the new build plan strategies and infrastructure, and the old reflection based strategies, policies, attributes, etc. I originally kept them in there for back compatibility, but at this stage it doesn't look like folks with existing OB customizations will be moving on to this version.

Since this means we have two ways to do everything, one of which isn't actually used, there's a lot of confusion when approaching OB2 for the first time. So we're thinking that getting rid of the older, unused stuff is a good idea. I see three basic things we could do:

  1. Don't do anything, deal with the confusion and write lots more docs.
  2. Delete the old code completely.
  3. Move the old code to a separate assembly, write docs about how you shouldn't need anything in it.

The simplest approach from my standpoint is to just delete it, as there's much less of a docs burden (even if we keep the old stuff in a separate assembly, we have to explain why and when to deploy it, when to use it, etc.) But I don't want to just chop folks off at the knees if these classes are important to people.

So, how many folks here are relying on those older strategies and policies? Should they survive?

-Chris
Apr 7, 2008 at 9:49 PM


ctavares wrote:

So, how many folks here are relying on those older strategies and policies? Should they survive?

-Chris


Don't yell at me ;) but I would vote for option #3, not to be difficult but because of my experience with trying to keep up with Microsoft's technologies (and glad to do so or we'd still be in DOS). "but at this stage it doesn't look like folks with existing OB customizations will be moving on to this version"; the stage will come where they will need to, want to and perhaps "have to" and if it is backwards compatible it will have the return on investment as it can be phased in.

Case in point I am following Michael Puleio's series very closely (and I'm extremely encouraged by this for the WCSF future) and will use what I learn to create a SCSF WorkItem utilizing OB2, my initial goals for this Contrib project are simple and conservative but judging by Michael's works has the potential to become more aggressive by me, or others in the community.






Apr 7, 2008 at 10:00 PM
I asked for opinions, no yelling here. Yet. ;-)

The other issue with keeping them around is that none of the old policies will do anything if added to an existing Unity container, since the strategies that consume them are not present. So more doc issues.
Apr 8, 2008 at 1:30 AM
I don't use them either right now.

What about you move them to the yet-still-to-come Contrib project?