On 11/9/06, Eran Chinthaka <[EMAIL PROTECTED]> wrote:
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,
After hanging about on [EMAIL PROTECTED] for a while it's pretty clear
that people don't like decisions being made on telecons, IRC or
anywhere other than the appropriate public mailing list. IMO something
as significant as this should have a vote on the list - it flushes out
concerns from every part of the community including those who aren't
on the telecon/IRC. BTW: I do apologize for not being on the call - I
have another weekly commitment at the same time which I'm trying to
move.
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.
I really *do* want Axis2 to use Woden - and work with everyone to get
the best solution here. I don't think the best solution is introducing
deprecation to an API that isn't finished. We need to be free to make
all the changes we want to between milestones up to v1.0 so we can get
the API right and in a good enough position so that subsequent changes
(if we need them :-) are easy to mark as deprecations.
IMO, snapshots are dangerous because without changing the
project.properties a new jar gets brought in, potentially breaking
compilation. Snapshot jars are defined as being subject to change.
Either this is ok because developers understand the risk and just fix
things when the dependencies change underneath them. Or it isn't
because someone is relying on the builds being good almost 100%. In
the latter case the project.properties should only depend on fixed
levels - e.g. Axiom 1.1 - after all the Axiom 1.1 distro is *never*
going to change.
With the Axis2 v1.1 branch you're certainly doing the latter and
depending on Woden M6.
If you're saying you need to do something similar for Axis2 trunk,
then I think you either need more frequent releases of Woden or
dated-snapshots which aren't quite releases, but definitely don't
change underneath you. I'm ok with both of these. If we do the first
then it'll give us more release practice :-) if the second then ...
well there's a problem with the 'dated snapshot' idea I hadn't
consdiered: when do you free up space on the server by deleting old
snapshots in order to create new ones.
We could have 3 dated snapshots at all times, when a new one is
created, the oldest one is deleted. Then any project wishing to use a
dated snapshot would copy it to some private space and hard code their
project.properties to it. When they want to move up to a new Woden
dated snapshot, copy the new one to your IDE, change
project.properties, build Axis2 and publish the Woden dated snapshot
to the Axis2 private space, and delete the old one.
This email has already got too long, sorry. Any comments?
Thanks,
Jeremy
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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
