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