Re: 2.0.1 and 2.1.0 timelines

[Eric Dalquist]

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

-Eric

On 03/29/2010 03:26 PM, Ate Douma wrote:

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.

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





- bumping trunk to next 2.0.2 maintenance release






Regards,

Ate

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

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

smime.p7s
Description: S/MIME Cryptographic Signature