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
