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>]

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
>>>
>>
>