Re: Next few releases (was Re: [VOTE] Pluto 1.1.4 Release)

[Elliot Metsger]

David H. DeWolf wrote:


[EMAIL PROTECTED] wrote:

I am very much against moving toward a 1.2.0 release. We should not 
get mired in a 1.2.x release cycle of a JSR-168 impl. We need to start 
moving toward jsr-286. The jsr-286 EG will be releasing a public draft 
soon that is feature complete. Torsten's work in the 286 branch has 
almost caught up with the draft spec. Both Exo and JBoss portal has 
preliminary (alpha/beta) jsr-286 releases. We should not be that far 
behind.

When, assuming this is a goal, is a good time for 286 to get promoted to 
trunk?  And if so, what is the best way to go about doing this? 
Backporting 286 patches from the branch back to trunk?

There's no reason why we can't do both.  OS is about scratching your own 
itch.  If someone wants to work on 1.2.x, then go for it.  If you want 
to focus on 2.x, then by all means - do it!  Shoot, if someone wanted to 
dig up 1.0.x they are welcome to do that as well.

Sure, but it helps to have the community in agreement if not to marshal 
resources at least to have their good will.  In some cases community 
coordination is essential to success.  The reality is having the itch 
isn't always enough.




David


/Craig



*Elliot Metsger <[EMAIL PROTECTED]>*

07/16/2007 10:00 AM
Please respond to
pluto-dev@portals.apache.org


    
To
    pluto-dev@portals.apache.org
cc
    
Subject
    Re: [VOTE] Pluto 1.1.4 Release


    





Looks like the changes snuck in between the 1.1.2 and 1.1.3 release with
PLUTO-350 (r523130) - the relative URL provider.  I'm thinking we could
probably take it out, but I haven't taken a thorough look.

Of course, since the change is out there with 1.1.3, 1.1.3 users who
move to 1.1.5 will be broken.

We could re-release this 1.1.4 candidate as a 1.2.0, and put a note on
the website noting the 1.1.3 incompatibility.  Or just release 1.1.5 and
retract 1.1.3?

Elliot

David H. DeWolf wrote:
 > -1
 >
 > 1.1.3 and 1.1.4 should be backwards compatible (binary and runtime
 > compat). This looks to me like we introduced an incompatibility.  
In the
 > meantime, is there a workaround we can use in order to get 1.1.5
 > released without this incompatibility?
 >
 > This type of change can be added to 1.2.x BUT should be specifically
 > mentioned in an "upgrade" guide.
 >
 > David
 >
 > Charles Severance wrote:
 >> Elliot,
 >>
 >> Switching from 1.1.3 to 1.1.4 - Sakai compile fails with the 
following:
 >>
 >> 
/Users/csev/dev/sakai/portal/portal-render-impl/impl/src/java/org/sakaiproject/portal/render/portlet/services/SakaiPortalCallbackService.java:128: 

 >> 
org.sakaiproject.portal.render.portlet.services.SakaiPortalCallbackService.SakaiPortletURLProvider 

 >> is not abstract and does not override abstract method
 >> isSecureSupported() in org.apache.pluto.spi.PortletURLProvider
 >>         class SakaiPortletURLProvider implements PortletURLProvider
 >>
 >> Has an API changed?  I am happy to update Sakai, adding methods or
 >> whatever - let me know if this was an intentional change.
 >>
 >> /Chuck
 >>
 >>