Dave wrote:
On 3/1/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
Elias Torres wrote:
> I was wondering where new 4.0 work should go in: trunk or 4.0 branch?
> I'm worried about using 4.0 branch because it has been taken over by
JPA
> work and I don't deal with the work in progress there. Could we make a
> branch for JPA-only and have a 4.0 branch for smaller work items that
> won't break the rest of app for me (and others) to work on?
Well, this definitely needs a decision. My take is that the current
trunk (representing 3.2-dev) is basically frozen aside from fixes that
will be required to polish the 3.2 release. So as soon as 3.1 is final
and is released we should start the 3.2 release process and try to get
that out the door and be done with the 3.x tree.
New features like the ones you proposed for 4.0 should be done in a 4.0
branch and that's where I plan to do my development now. The problem is
the JPA and datamapper stuff which is in there now is not stable yet and
I don't think there is a near term ETA for when we would all be
convinced it is stable, so I would agree that we should consider
creating a new 4.0 branch from the current trunk and moving the current
4.0 branch to be a JPA branch.
That way main development can continue in the 4.0 branch while the JPA
work happens, and the JPA branch would essentially be merging changes
from the 4.0 branch and not the trunk.
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?
-- Allen
- Dave
