Elliot,
We need to hear from Torston, and, hopefully, Stefan on this issue. Stefan should also comment on the 286 spec's time line.
I'd like to merge the 286 branch with the trunk and then move 286 into the trunk. But if the community is still hot for a 1.2 release, we should do it from the trunk, but try to commit all 1.2 patches to the 286 branch if it is not incompatible with the 286 implementation.
Java 5 and JAXB are being used in the 286 branch, so I do not see the point in a 1.2 version. We have a stable 1.x line now. We should move on (IMHO).
/Craig
/Craig
To: [email protected]
From: Elliot Metsger <[EMAIL PROTECTED]>
Date: 07/16/2007 03:17PM
Subject: Re: Next few releases (was Re: [VOTE] Pluto 1.1.4 Release)
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
>> >>
>> >>
>>
>
>
