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
