That's a better idea and I should be able to set things straight in the next 20 mins.
- Dave On 3/2/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
I'm sorry if this is being really picky, but this is not exactly what I thought you were going to do when creating this branch. My expectation was ... svn move branches/roller_4.0 branches/roller_4.0_newbackend svn copy trunk branches/roller_4.0 What you did is definitely not the same and, while it may be that I am just overly picky, I think it would be more appropriate. The problem with leaving all the existing new backend work in the 4.0 branch is exactly what I said before, if I add a new method to a manager then the code is going to expect me to put it in 3 manager impls to build again, and that's what I want to avoid. Besides, there is no reason to leave that code in the new 4.0 branch since nobody is going to work on it there. My personal opinion as that we should do this now ... svn remove branches/roller_4.0 svn copy trunk branches/roller_4.0 -- Allen Dave wrote: > I made some small doc and javadoc fixes in the trunk, synced trunk to > roller_4.0, made the classic Hibernate back-end the default in > roller_4.0 and created a new branch called roller_4.0_newbackend. > > Elias and Allen, you're free to do non-JPA and non-iBatis related work > in roller_4.0. > > - Dave > > > > On 3/1/07, Dave <[EMAIL PROTECTED]> wrote: >> On 3/1/07, Allen Gilliland <[EMAIL PROTECTED]> wrote: >> > Elias Torres wrote: >> > > I have 2 proposals, plus 3 more coming (Reverse Proxy, Lucene Search >> > > revamping and continue discussing language detection). Everything >> else >> > > is little bug fixes here and there. >> > > >> > > All of those proposals can be worked in w/o a need of a major branch >> > > (the worse would be to break search for a few days or such). >> > > >> > > If 4.0 branch is stable enough, then I got my answer: work on >> branch 4.0 >> > > . I don't want to force you to work on a branch unless it's counter >> > > productive to the rest of us. >> > >> > I think a special branch for the new backend / persistence bake-off >> > makes the most sense and provides the cleanest approach, so that's what >> > I vote for. >> >> OK given the number of new 4.0 proposals coming and your apparently >> more flexible time-lines, I agree, we need a new roller_4.0_backend >> branch. I will create one ASAP and make the roller_4.0 branch default >> to old-school Hibernate so we can have maximum stability there. >> >> Thanks for sharing your plans. From my point of view, the sooner we >> can lock down 4.0 feature set and time-lines the better. >> >> - Dave >>
