Torsten,
Do you believe that it would be easier to merge the branch into the
trunk or merge the trunk changes since it was branched into the branch?
David
Torsten Dettborn wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Craig,
i would like moving toward the "jsr-286". What David has already
said, everyone must decide himself on what implementation he want's to
work. But for the jsr-286 implementation it is important to make a cut
to the 168 implementation. I don't know what version is best for.
Torsten
David H. DeWolf schrieb:
[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
>>>
>>>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGnLxO0Ji0BqEIlIURAgX/AJ4rKefMJds0qKV3zwPItvaoUMBq3QCdHucL
6pEXFvTr+vdArIPA7IqrPJg=
=wc8D
-----END PGP SIGNATURE-----
