You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Elias Torres <el...@torrez.us> on 2007/03/01 19:52:08 UTC
4.0 Branch, JPA, trunk, etc
Hi guys,
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?
I hope you are having a nice day!
-Elias
Re: 4.0 Branch, JPA, trunk, etc
Posted by Elias Torres <el...@torrez.us>.
Thanks!
-Elias
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 <sn...@gmail.com> wrote:
>> On 3/1/07, Allen Gilliland <al...@sun.com> 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
>>
>
Re: 4.0 Branch, JPA, trunk, etc
Posted by Dave <sn...@gmail.com>.
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 <al...@sun.com> 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 <sn...@gmail.com> wrote:
> >> On 3/1/07, Allen Gilliland <al...@sun.com> 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
> >>
>
Re: 4.0 Branch, JPA, trunk, etc
Posted by Allen Gilliland <al...@sun.com>.
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 <sn...@gmail.com> wrote:
>> On 3/1/07, Allen Gilliland <al...@sun.com> 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
>>
Re: 4.0 Branch, JPA, trunk, etc
Posted by Elias Torres <el...@torrez.us>.
+1
Allen Gilliland wrote:
>
>
> Dave wrote:
>> On 3/2/07, Allen Gilliland <al...@sun.com> wrote:
>>> maybe the best thing to do technically is to branch the trunk for 3.2
>>> now and make the trunk the official 4.0-dev place?
>>
>> Even better....
>>
>> Here's what we will have:
>>
>> trunk - for 4.0 development
>>
>> branches/roller_3.2 - for 3.2, which is closed to new features
>>
>> branches/roller_4.0_newbackend - for new backend dev
>>
>> Any objections to that?
>
> nope, that sounds like a good plan to me.
>
> -- Allen
>
>
>>
>>
>> - Dave
>
Re: 4.0 Branch, JPA, trunk, etc
Posted by Allen Gilliland <al...@sun.com>.
Dave wrote:
> On 3/2/07, Allen Gilliland <al...@sun.com> wrote:
>> maybe the best thing to do technically is to branch the trunk for 3.2
>> now and make the trunk the official 4.0-dev place?
>
> Even better....
>
> Here's what we will have:
>
> trunk - for 4.0 development
>
> branches/roller_3.2 - for 3.2, which is closed to new features
>
> branches/roller_4.0_newbackend - for new backend dev
>
> Any objections to that?
nope, that sounds like a good plan to me.
-- Allen
>
>
> - Dave
Re: 4.0 Branch, JPA, trunk, etc
Posted by Craig L Russell <Cr...@Sun.COM>.
On Mar 2, 2007, at 10:01 AM, Dave wrote:
> On 3/2/07, Allen Gilliland <al...@sun.com> wrote:
>> maybe the best thing to do technically is to branch the trunk for 3.2
>> now and make the trunk the official 4.0-dev place?
>
> Even better....
>
> Here's what we will have:
>
> trunk - for 4.0 development
>
> branches/roller_3.2 - for 3.2, which is closed to new features
>
> branches/roller_4.0_newbackend - for new backend dev
>
> Any objections to that?
Sounds good.
Craig
>
>
> - Dave
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: 4.0 Branch, JPA, trunk, etc
Posted by Dave <sn...@gmail.com>.
On 3/2/07, Allen Gilliland <al...@sun.com> wrote:
> maybe the best thing to do technically is to branch the trunk for 3.2
> now and make the trunk the official 4.0-dev place?
Even better....
Here's what we will have:
trunk - for 4.0 development
branches/roller_3.2 - for 3.2, which is closed to new features
branches/roller_4.0_newbackend - for new backend dev
Any objections to that?
- Dave
Re: 4.0 Branch, JPA, trunk, etc
Posted by Allen Gilliland <al...@sun.com>.
Elias Torres wrote:
> I hope I'm not making things more complicated, but I have a question:
>
> Is there any new development being done in trunk?
not really, just 3.2 bug fixing. 3.2 is closed to new features.
>
> Anything new whatsoever needs to be done in 4.0 branch, right?
pretty much, yes.
>
> Any bug fixes in 4.0 branch need to applied to trunk as well?
well, the idea is that bug fixes needed by 3.2 will go to trunk first
and then be merged to 4.0, but i see what you are getting at.
maybe the best thing to do technically is to branch the trunk for 3.2
now and make the trunk the official 4.0-dev place?
-- Allen
>
> -Elias
>
> 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 <sn...@gmail.com> wrote:
>>> On 3/1/07, Allen Gilliland <al...@sun.com> 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
>>>
Re: 4.0 Branch, JPA, trunk, etc
Posted by Elias Torres <el...@torrez.us>.
I hope I'm not making things more complicated, but I have a question:
Is there any new development being done in trunk?
Anything new whatsoever needs to be done in 4.0 branch, right?
Any bug fixes in 4.0 branch need to applied to trunk as well?
-Elias
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 <sn...@gmail.com> wrote:
>> On 3/1/07, Allen Gilliland <al...@sun.com> 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
>>
>
Re: 4.0 Branch, JPA, trunk, etc
Posted by Dave <sn...@gmail.com>.
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 <sn...@gmail.com> wrote:
> On 3/1/07, Allen Gilliland <al...@sun.com> 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
>
Re: 4.0 Branch, JPA, trunk, etc
Posted by Dave <sn...@gmail.com>.
On 3/1/07, Allen Gilliland <al...@sun.com> 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
Re: 4.0 Branch, JPA, trunk, etc
Posted by Allen Gilliland <al...@sun.com>.
Elias Torres wrote:
>
> Dave wrote:
>> On 3/1/07, Allen Gilliland <al...@sun.com> wrote:
>
> [snip]
>
>> Three reasons:
>> - A branch is additional work
I agree that a branch is a little bit of extra work, but I don't think
it's horrible.
>> - 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.
Problem here is that this can't happen in parallel all the time. What
if I am developing a pretty sizable new feature which requires backend
mods and I'm not going to be ready to commit it for a couple of weeks?
I don't want the various backend impls to be conflicting with my
development space regardless of the fact that I know you are willing to
fix up the JPA side once I commit.
>>
>> 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.
agreed, and I think that's basically what we are doing now. From what I
know right now I think that it would be a good idea to put the whole
persistence bake-off backend thing into it's own branch which is
separate from the official 4.0 dev branch. And since I have been doing
work on the JPA impl it means more work for me too and I am willing to
help with it.
>>
>> I thought that consensus was that Roller 4.0 is these things:
>> - New backend
I think we voted +1 to that idea, but we still need to vote +1 to the
actual implementation. "new backend" is pretty generic and we need to
keep working to figure out exactly what that means. so far the ideas
have been Datamapper, JPA, and iBatis, and just for completeness sake I
would argue that we should consider the idea that Hibernate would remain
the backend if we can't find a suitable alternative.
I think I've said this before, but my one condition here is that the new
backend has to be better than what we have now or it won't get my vote.
So while I voted +1 to the idea of a new backend, I still plan to vote
again when we see the actual implementations.
>> - 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 not sure about this consensus, but that's probably because I wasn't
> around. I see a 4.0 proposal, but I didn't think that Roller 4.0 was
> closed for new proposals.
>
> I'm trying to sync up with 4.0 work we did for Lotus Connections and it
> wasn't until now that I'm ready to write proposals and work on them
> together with the community.
It's definitely not closed for proposals. I have a few more that I am
doing as well.
>
> However, a month for all that? It seems crazy to me to think that we'll
> replace the UI, back-end, new Java version in a month.
I think that time frame is based on our development cycle which has been
such that 3.2 development has basically been done for a while now, so
it's time for 4.0. However, 4.0 is a major release and I don't think we
should rush things. I am actually pretty flexible on the 4.0 timing,
but I think that end of March is a good time to be closing off 4.0 for
new proposals and starting to focus on wrapping up new features and
thinking about stabilization. I don't think that end of March is when
4.0 needs to be code complete though.
>
>> I'm guessing Elias could get his features in pretty quicky and late
>
> I'd hope that anything I want to do will not slow you down. But I don't
> want to wait til 4.1. Roller is really fast at moving versions, but
> slower at releasing them, therefore I need to catch up with your
> development schedule not your release schedule.
I don't think that's the case. I think your timing is perfect for 4.0
work and your proposals are right on schedule.
>
>> 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?
>
> I'd hope not.
>
>> 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?
>
> I'm not sure why the topic changed into time frames. What I think Allen
> and I were asking was where to do the work? For example I don't know
> what you are doing with JPA (e.g. I thought you were ripping everything
> out to do a straight JPA, else we are just continuing with our multiple
> back-end story). If so, I didn't want to be working with a branch that
> had all of that going.
I agree and I think this is another good example of why a persistence
bake-off branch makes the most sense. Then we can add the iBatis
backend in there and use it as part of the comparison for new backends.
>
> 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.
-- Allen
>
> -Elias
>
>
>> - Dave
>>
Re: 4.0 Branch, JPA, trunk, etc
Posted by Elias Torres <el...@torrez.us>.
Dave wrote:
> On 3/1/07, Allen Gilliland <al...@sun.com> wrote:
[snip]
>
> 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 not sure about this consensus, but that's probably because I wasn't
around. I see a 4.0 proposal, but I didn't think that Roller 4.0 was
closed for new proposals.
I'm trying to sync up with 4.0 work we did for Lotus Connections and it
wasn't until now that I'm ready to write proposals and work on them
together with the community.
However, a month for all that? It seems crazy to me to think that we'll
replace the UI, back-end, new Java version in a month.
>
> I'm guessing Elias could get his features in pretty quicky and late
I'd hope that anything I want to do will not slow you down. But I don't
want to wait til 4.1. Roller is really fast at moving versions, but
slower at releasing them, therefore I need to catch up with your
development schedule not your release schedule.
> 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?
I'd hope not.
>
> 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?
I'm not sure why the topic changed into time frames. What I think Allen
and I were asking was where to do the work? For example I don't know
what you are doing with JPA (e.g. I thought you were ripping everything
out to do a straight JPA, else we are just continuing with our multiple
back-end story). If so, I didn't want to be working with a branch that
had all of that going.
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.
-Elias
>
> - Dave
>
Re: 4.0 Branch, JPA, trunk, etc
Posted by Dave <sn...@gmail.com>.
On 3/1/07, Allen Gilliland <al...@sun.com> 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
Re: 4.0 Branch, JPA, trunk, etc
Posted by Allen Gilliland <al...@sun.com>.
Dave wrote:
> On 3/1/07, Allen Gilliland <al...@sun.com> 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
Re: 4.0 Branch, JPA, trunk, etc
Posted by Dave <sn...@gmail.com>.
On 3/1/07, Allen Gilliland <al...@sun.com> 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?
- Dave
Re: 4.0 Branch, JPA, trunk, etc
Posted by Allen Gilliland <al...@sun.com>.
Elias Torres wrote:
> Hi guys,
>
> 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.
-- Allen
>
> I hope you are having a nice day!
>
> -Elias