Chinthaka, I don't think Jeremy was trying to penalize you for depending on a milestone release. He was saying you should depend on milestone releases. His concern was that you want to depend on snapshots (in-between Milestone releases) but still expect the backward compatibility of a release. As per our previous discussion and Jeremy's email, this introduces risk to our development efforts when we are still moving towards a stable 1.0 release. If we were already stabilized on a 1.0 release or later, then backward compatibility would be the norm and this problem would not arise or we'd have a better deprecation strategy.
Anyway, as agreed - let's go with the deprecation approach and if there are
any significant design changes that mean old methods must be removed from
trunk without deprecation (for example, because they will no longer
compile) then we can discuss further options. One option might be the dated
snapshot Jeremy suggests. Another option could be branching trunk prior to
the method removal.
Woden developers should check first if Axis2 is actually using a Woden
method that needs to be removed or changed. If so, deprecate the Woden
method. If not, just remove/change it.
Jeremy raises a good point which we touched on in the telecon about how
long a deprecated method will be required by Axis2. We agreed to keep
deprecated methods in Woden for 1 milestone release. So it's up to Axis2
developers to ensure any Axis2 dependency on a deprecated method is removed
in that timeframe. And if Woden milestones are more frequent than Axis2
releases then the Axis2 developers may need to deliver Axis2 changes to
users of the current Axis2 release if they want it to depend on the latest
Woden.
Woden developers should annotate deprecation comments with the replacement
method and with the timeframe or release in which the deprecated method can
be removed.
regards,
John Kaputin
Eran Chinthaka
<[EMAIL PROTECTED]
urce.lk> To
[email protected]
09/11/2006 07:39 cc
Subject
Please respond to Re: Minutes of the Woden Status
[EMAIL PROTECTED] Telecon, 2006-11-07
he.org
Hi Jeremy,
I think we have already agreed in the weekly chat on this. Perhaps the
meeting minutes are not explaining it enough.
We agreed to deprecate a methods and vars, and at least keep them for
one more Woden release. In this way, our smart IDEs will complain about
the deprecations and we, in Axis2 team, will be able to correct them. It
is far more better than just getting a compilation error.
And when you deprecate methods or variables, please put some additional
info, inside @deprecated to, to direct user to use the new methods or
attributes and their locations.
Anyway, do not please try to penalize us for depending on a milestone
release. We definitely want to use the component and you also might
like that to be used. If sudden things like, just removing methods
happens then we in Axis2 are in trouble which is not good for both of
the communities.
Thanks,
Chinthaka
Jeremy Hughes wrote:
> On 11/7/06, Lawrence Mandel <[EMAIL PROTECTED]> wrote:
> [snip]
>> 3.Development Discussion - All
>>
>> Chinthaka: I had a problem when I moved up from M6 to a snapshot. A
>> method
>> has been removed.
>
> Surely that is the nature of using snapshots. When you want stability
> you use the milestone release itself and you do that consciously - ie
> when you move from M5 to M6 you build and test in a sandbox and
> resolve any issues - you don't rely on the automated build machine to
> get it right.
>
>> John: Would it be OK if we keep the method for one milestone of Woden?
>> Chinthaka: That would be better. At least we'd get a deprecation notice.
>
> How will we know we can remove the deprecated methods. Axis2 could
> still be relying on the deprecated methods when we remove them.
>
> In some cases we might have to remove methods where the design changes
> sufficiently that means we can't keep the method in situ. While this
> would be unacceptable for a v1.0->v1.1 delivery I think it's fine
> while we are in the middle of developing v1.0.
>
> Howabout a hybrid approach. Include a date in the filename of the
> SNAPSHOT file so that you (Axis2 community) can choose when to move up
> to a new SNAPSHOT level - doing all the changes and testing in a
> sandbox you need. You get the control and the frequent updates (more
> frequent than milestone builds :-)
>
>> Lawrence: I don't want this to slow down Woden development. We haven't
>> even
>> had a release yet.
>> Arthur: How about if we build Axis2 and fix anything we break?
>> Chinthaka: That will likely lead to problems. I'll see what we can do
>> on the
>> Axis2 side to reduce the problems for these changes but I think keeping
>> deprecated methods for one Woden milestone will work.
>> Lawrence: We should announce all major changes on the woden-dev list.
>
> Cheers,
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
(See attached file: signature.asc)
signature.asc
Description: Binary data
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
