Hi all, Thanks for all of the hard to work in getting a new release ready. Its good to see some of the improvements in the portal implementations as well; I know that this is not really the goal of the Pluto project, but I think that having a basic, reliable portal is a good starting point for people trying to utilize the container, as well as for people who are simply trying to test vendor-independent portlet apps.
I've been working with 1.1.4, and I have not run into any problems, so I am also going to vote +1 for its release. Thanks for your hard work, Ben On Mon, 2007-07-16 at 13:56 -0400, Elliot Metsger wrote: > I want to put out quality software, and adhere to our principles of > backwards compatibility. > > However, having an incompatible release (1.1.3 incompatible with > previous 1.1.x releases) already out muddies the waters. > > I agree with Craig and David - lets move forward with 1.1.4, maintaining > compatibility between 1.1.3 and 1.1.4, and document the incompatibility > of the PortletURLProvider interface on the website. If the community > wants incompatibility documented in the 1.1.4 distribution release > notes, we will need to re-cut a 1.1.5. > > If people are in agreement, the original vote proposal still stands. > > +1 for the original vote proposal: release 1.1.4 > > Elliot > > David H. DeWolf wrote: > > Uck! In that case, I'll retract my -1 and let the community decide > > what's best. I'd say that it's best to keep compatibility moving > > forward (and not worry about previous mistakes, besides documenting > > them). . .so our goal is to be compatible with 1.1.3. > > > > In other words, my suggestion would be to move forward with 1.1.4. > > > > > > David > > > > Elliot Metsger wrote: > >> 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 > >>>> > >>>> > >> >
