-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi David, under the aspect, that people want to finish the 1.2 Version, i think it would better to merge a fixed version to the brunch. So we can finish the version 1.2 and merge the "actual" trunk into the branch. After finishing do we open version 2.0?
Torsten Torsten Dettborn schrieb: > Hi David, > > this is a good and important question. I don't know what's the > best, i will think about it. > > Torsten > > David H. DeWolf schrieb: >> 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: 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 iD4DBQFGnwmN0Ji0BqEIlIURAm3+AJ4h8RW5+9v3q0qcaiSyfk2ftYGZfACY8GQh GjRy7FWvL6ObIzqASPRnfg== =rPoC -----END PGP SIGNATURE-----
