Craig
sorry i'm super sporadic today, and i don't mean to start all these
threads all having to do with the same issue. This is probaby the best
thread to discuss this stuff.
What about just beginning to promote 286 code to the trunk, and doing
away with the 286 branch? We'd do it by applying diffs of the 286
branch to trunk.
Since we've never done a 1.2 release, we can re-branch for that later if
we want. Since svn is so cool :)
Elliot
[EMAIL PROTECTED] wrote:
David,
Thanks for reminding me about this. Yes, we can all go off in any number
of directions if we want.
I intend to start focussing my efforts on the 286-COMPATILIBITY branch.
merging the code with the current trunk and pushing out a Pluto 2.0 alpha
or beta release. I hope that others in the Pluto community will join me in
that effort.
/Craig
"David H. DeWolf" <[EMAIL PROTECTED]>
07/16/2007 12:44 PM
Please respond to
[email protected]
To
[email protected]
cc
Subject
Next few releases (was Re: [VOTE] Pluto 1.1.4 Release)
[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
[email protected]
To
[email protected]
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
>>
>>
