On 3/1/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
> I don't see why that is necessary. If the default setting in
> roller.properties is for the old-school Hibernate back-end, then the
> roller_4.0 branch should be completely stable and if it isn't it
> should be immediately fixed. It's only the JPA back-ends that are not
> stable right now.
>
> Currently we're defaulting to JPA, but I'll change that to Hibernate
> so you work in the branch without messing with JPA. Why won't that
> work?
Well, technically it can work, but we would have to setup more than just
what you described. The big hang up is that we don't want to compile
any of the other backend code so that in the event that someone breaks
something in the JPA or Datamapper impl that it doesn't affect other
work. These kinds of things arise when we might do a merge from the
trunk which did updates to the backend and aren't reflected in the JPA
or Datamapper impls so it breaks the build. The other, and more
notable, case being that our new development efforts require changes to
backend code and we don't want to have to do that against 3 backends to
keep the build working.
I think the bigger issue here though is that this is what branching is
for, it's to isolate development that is not stable so that it doesn't
affect the rest of the development. So quite frankly i would turn the
question the other way around and ask, why not a branch?
Three reasons:
- A branch is additional work
- We're all working on the same thing, i.e. 4.0
- I'm dedicated to actively maintaining the JPA back-end and keeping
it in sync with anything Allen or Elias or anybody else does,
including new manager interfaces and methods.
That said, I'm not totally opposed to a branch, but I think we need to
coordinate, sync-up and perhaps better define 4.0 and the time frame.
Maybe we need one, maybe we don't.
I thought that consensus was that Roller 4.0 is these things:
- New backend
- Start of Struts2 migration
- Introduce requirement for JDK 5
- Other features Allen wants?
And Allen and I both wanted to have some stability by late March.
I'm guessing Elias could get his features in pretty quicky and late
March could still work, but what about JPA stability and what about
iBatis vs. JPA. Do we pick JPA over iBatis just because iBatis isn't
ready by arbitrary date X?
My primary goal is having a stable JPA implementation by late March.
I'm willing to be flexible on pretty much everything else.
Whats the new consensus? What do you guys need and by when?
- Dave
