Alfred Nathaniel skrev:
On Tue, 2007-08-07 at 09:46 +0200, Daniel Fagerstrom wrote:
Unfortunately it is more complicated than that. The non-compatible
change is that Request.getSession switches return value from
o.a.c.environment.Session to javax.servlet.http.HttpSession and that
Request.getCookie switch return value from o.a.c.environment.Cookie to
javax.servlet.http.Cookie. You, of course, cannot have a method with two
different return types. So there is no point in deprecating
Request.getSession and Request.getCookie in 2.2 as we not will have any
replacements until 2.3 in that case. So the deprecation mechanism is
AFAICS not applicable.
How about this:
1.) In 2.1.11 add Request.getCocoonSession and Request.getCocoonCookie
and deprecate the current methods.
2.) In 2.2 let o.a.c.e.XXX extend the standard interfaces, change return
types of getXXX methods and deprecate getCocoonXXX methods.
Seem like a good suggestion to me. It will give users that going the
path of first upgrading to 2.1.11 and then to 2.2 a smooth path and the
appropriate deprecation warnings when they build their own code. It is
important that we document what we are up to well in 2.1.11 so that
users understand what is going on and where it is leading.
3.) In 2.3 remove getCocoonXXX and o.a.c.e.XXX.
Removing o.a.c.e.XXX is a little bit more complicated as the Request
interface has a few methods for handling sub sitemap paths. But maybe we
could introduce a minimal interface for just those methods and deprecate
o.a.c.e.XXX. Anyway, from our current speed in switching minor version,
we might not be in such a hurry in deciding the exact details of 2.3 ;)
That allows for a smoother transition path for user components because
they can be made forwards compatible to work for both 2.1.11+ and 2.2
(if Session/Cookie is the only incompatibility?).
Yes, AFAICS, I tried the changes locally to be able to see the consequences.
In any case, I am -1 on creating a 2.3 branch in the near future. First
we must get out 2.2 and let it season on trunk to reach production
quality. The parallel maintenance and forward and backward porting
between 2.1 and 2.2 was a terrible resource drain which we should try to
avoid as far as possible.
Agree, I'll be -1 on branches as well.
/Daniel
