2.0.1 and 2.1.0 timelines

[Eric Dalquist <er...@doit.wisc.edu>]

Ate,

What is your timeline for 2.0.1? I think I'd like to look at creating a 
2.1.0 branch to do some refactoring as far as what goes where in the 
pluto modules as well as some new features and changes. If I start that 
branch this week will it interfere with the 2.0.1 work?

I think the first place I'll be focusing is the portlet registration 
process. As far as I can tell the current implementation breaks if the 
portal webapp is ever redeployed. Portlets appear to start a Timer when 
they init to register themselves with a portal injected implementation 
class. If the portal is restarted that class is no longer valid but 
there is no way for the redeployed portal to still access the previously 
registered portlets. I have a few ideas on how to address this but I'll 
post more detail once I've actually dug in a little further.

-Eric

Re: 2.0.1 and 2.1.0 timelines

[Ate Douma <at...@douma.nu>]

On 04/19/2010 10:02 PM, Eric Dalquist wrote:
> Well I disappeared for some family reasons and it looks like this is
> semi-resolved since 2.0.1 is being released right now.
>
> I would advocate for creating a 2.0-patches branch off of the 2.0.1
> release that will allow 2.1 development to occur without potentially
> causing problems for a 2.0.2 if the need arises. We would just need to
> be aware that fixing bugs requires changes in both trunk and the branch.
> Does this sound like a reasonable approach to take once the 2.0.1
> release work is completely done with? Pluto doesn't appear to have many
> branches to date so are there any suggestions for a branch name? In
> absence of other ideas I would suggest "pluto-2.0.x" which fits with the
> "pluto-1.1.x" branch that exists in SVN.

+1 to all of the above.

I intend to do some 2.0.2 fixes and a new bugfix release of that within the next few weeks.
When you create the 2.0.x branch, I'll start fixing both trees after that.

Ate

>
> -Eric
>
> On 03/29/2010 03:26 PM, Ate Douma wrote:
>> Hi Eric,
>>
>> On 03/28/2010 02:35 PM, Eric Dalquist wrote:
>>> Ate,
>>>
>>> What is your timeline for 2.0.1? I think I'd like to look at creating a
>>> 2.1.0 branch to do some refactoring as far as what goes where in the
>>> pluto modules as well as some new features and changes. If I start that
>>> branch this week will it interfere with the 2.0.1 work?
>> I don't think so, as branches never do :)
>> I'm a bit too busy with some remaining work on Jetspeed-2 right now to
>> have finished up Pluto 2.0.1 already, but as you might have noticed I
>> closed one open issue and moved 3 (all Weblogic related) to next
>> maintenance version 2.0.2
>> There are only 4 issues for 2.0.1 remaining, two assigned to me which
>> I'll try to look into this week.
>> The other two are assigned to David Jencks who I will ping myself how
>> we best can resolve them quickly (PLUTO-586 being easy I think).
>>
>> So, I don't think there need to be many changes on trunk anymore
>> before we can wrap it and call a vote for the 2.0.1 release.
>> Branching now shouldn't pose too much of a problem therefore as not
>> much trunk changes need to be merged in to get it in sync with the
>> 2.0.1 release.
>>
>> However, as you indicated you'd like to start a 2.1.0 like branch
>> (which is fine IMO), we need to decide what the next trunk version
>> should become:
>> - bumping trunk to next 2.0.2 maintenance release
>> - promoting your 2.1.0 branch as trunk and create a separate 2.0.x
>> maintenance branch like we have for the 1.1.x versions
>>
>> I'm probably fine with either way but other committers should chime in
>> too IMO.
>> It also depends on how much in flux the 2.1.0 development will become
>> which version we'll switch to for next version of Jetspeed (that is:
>> if/once we need to upgrade to a "trunk" development version, e.g. need
>> changes/fixes of our own).
>>
>> Anyway, we can decide this after 2.0.1 is released and always swap
>> between 2.0.2-SNAPSHOT and 2.1.0-SNAPSHOT for trunk when needed.
>>
>> Regards,
>>
>> Ate
>>
>>>
>>> I think the first place I'll be focusing is the portlet registration
>>> process. As far as I can tell the current implementation breaks if the
>>> portal webapp is ever redeployed. Portlets appear to start a Timer when
>>> they init to register themselves with a portal injected implementation
>>> class. If the portal is restarted that class is no longer valid but
>>> there is no way for the redeployed portal to still access the previously
>>> registered portlets. I have a few ideas on how to address this but I'll
>>> post more detail once I've actually dug in a little further.
>>>
>>> -Eric
>>>
>>
>

Re: 2.0.1 and 2.1.0 timelines

[Eric Dalquist <er...@doit.wisc.edu>]

Well I disappeared for some family reasons and it looks like this is 
semi-resolved since 2.0.1 is being released right now.

I would advocate for creating a 2.0-patches branch off of the 2.0.1 
release that will allow 2.1 development to occur without potentially 
causing problems for a 2.0.2 if the need arises. We would just need to 
be aware that fixing bugs requires changes in both trunk and the branch. 
Does this sound like a reasonable approach to take once the 2.0.1 
release work is completely done with? Pluto doesn't appear to have many 
branches to date so are there any suggestions for a branch name? In 
absence of other ideas I would suggest "pluto-2.0.x" which fits with the 
"pluto-1.1.x" branch that exists in SVN.

-Eric

On 03/29/2010 03:26 PM, Ate Douma wrote:
> Hi Eric,
>
> On 03/28/2010 02:35 PM, Eric Dalquist wrote:
>> Ate,
>>
>> What is your timeline for 2.0.1? I think I'd like to look at creating a
>> 2.1.0 branch to do some refactoring as far as what goes where in the
>> pluto modules as well as some new features and changes. If I start that
>> branch this week will it interfere with the 2.0.1 work?
> I don't think so, as branches never do :)
> I'm a bit too busy with some remaining work on Jetspeed-2 right now to 
> have finished up Pluto 2.0.1 already, but as you might have noticed I 
> closed one open issue and moved 3 (all Weblogic related) to next 
> maintenance version 2.0.2
> There are only 4 issues for 2.0.1 remaining, two assigned to me which 
> I'll try to look into this week.
> The other two are assigned to David Jencks who I will ping myself how 
> we best can resolve them quickly (PLUTO-586 being easy I think).
>
> So, I don't think there need to be many changes on trunk anymore 
> before we can wrap it and call a vote for the 2.0.1 release.
> Branching now shouldn't pose too much of a problem therefore as not 
> much trunk changes need to be merged in to get it in sync with the 
> 2.0.1 release.
>
> However, as you indicated you'd like to start a 2.1.0 like branch 
> (which is fine IMO), we need to decide what the next trunk version 
> should become:
> - bumping trunk to next 2.0.2 maintenance release
> - promoting your 2.1.0 branch as trunk and create a separate 2.0.x 
> maintenance branch like we have for the 1.1.x versions
>
> I'm probably fine with either way but other committers should chime in 
> too IMO.
> It also depends on how much in flux the 2.1.0 development will become 
> which version we'll switch to for next version of Jetspeed (that is: 
> if/once we need to upgrade to a "trunk" development version, e.g. need 
> changes/fixes of our own).
>
> Anyway, we can decide this after 2.0.1 is released and always swap 
> between 2.0.2-SNAPSHOT and 2.1.0-SNAPSHOT for trunk when needed.
>
> Regards,
>
> Ate
>
>>
>> I think the first place I'll be focusing is the portlet registration
>> process. As far as I can tell the current implementation breaks if the
>> portal webapp is ever redeployed. Portlets appear to start a Timer when
>> they init to register themselves with a portal injected implementation
>> class. If the portal is restarted that class is no longer valid but
>> there is no way for the redeployed portal to still access the previously
>> registered portlets. I have a few ideas on how to address this but I'll
>> post more detail once I've actually dug in a little further.
>>
>> -Eric
>>
>

Re: 2.0.1 and 2.1.0 timelines

[Ate Douma <at...@douma.nu>]

Hi Eric,

On 03/28/2010 02:35 PM, Eric Dalquist wrote:
> Ate,
>
> What is your timeline for 2.0.1? I think I'd like to look at creating a
> 2.1.0 branch to do some refactoring as far as what goes where in the
> pluto modules as well as some new features and changes. If I start that
> branch this week will it interfere with the 2.0.1 work?
I don't think so, as branches never do :)
I'm a bit too busy with some remaining work on Jetspeed-2 right now to have finished up Pluto 2.0.1 already, but as you might have noticed I 
closed one open issue and moved 3 (all Weblogic related) to next maintenance version 2.0.2
There are only 4 issues for 2.0.1 remaining, two assigned to me which I'll try to look into this week.
The other two are assigned to David Jencks who I will ping myself how we best can resolve them quickly (PLUTO-586 being easy I think).

So, I don't think there need to be many changes on trunk anymore before we can wrap it and call a vote for the 2.0.1 release.
Branching now shouldn't pose too much of a problem therefore as not much trunk changes need to be merged in to get it in sync with the 2.0.1 
release.

However, as you indicated you'd like to start a 2.1.0 like branch (which is fine IMO), we need to decide what the next trunk version should 
become:
- bumping trunk to next 2.0.2 maintenance release
- promoting your 2.1.0 branch as trunk and create a separate 2.0.x maintenance branch like we have for the 1.1.x versions

I'm probably fine with either way but other committers should chime in too IMO.
It also depends on how much in flux the 2.1.0 development will become which version we'll switch to for next version of Jetspeed (that is: 
if/once we need to upgrade to a "trunk" development version, e.g. need changes/fixes of our own).

Anyway, we can decide this after 2.0.1 is released and always swap between 2.0.2-SNAPSHOT and 2.1.0-SNAPSHOT for trunk when needed.

Regards,

Ate

>
> I think the first place I'll be focusing is the portlet registration
> process. As far as I can tell the current implementation breaks if the
> portal webapp is ever redeployed. Portlets appear to start a Timer when
> they init to register themselves with a portal injected implementation
> class. If the portal is restarted that class is no longer valid but
> there is no way for the redeployed portal to still access the previously
> registered portlets. I have a few ideas on how to address this but I'll
> post more detail once I've actually dug in a little further.
>
> -Eric
>