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