IMHO, for the benefit of the users, if deprecation and obsoleting
policies are defined, it would be great.
I mean, say you define a time period for obsoleting a deprecated
feature, rather than obsoleting in an ad-hoc manner, so that all know
how long a deprecated feature would be there before they can migrate to
the new one.
Thanks,
Samisa...
Deepal Jayasinghe wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all;
As you know in the current SVN we have our old client side codes (Call
, InOutMEPClient etc..) and no body is using those, in fact they are
marked as deprecated.
So what if we move them to scratch area , keeping them in the main
source tree make no sense to me :)
here is my +1 for moving them away from Axis2 main tree , and I like
to do that before next release.
????????????????
- --
Thanks,
Deepal
................................................................
~Future is Open~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFEECFljOGcXNDx0CARAhNuAJ48vDhyQZLeE+ttK91Cfk4AqZR78QCeIWci
58/HlGJewGnSEJz7S99Owug=
=+vOj
-----END PGP SIGNATURE-----
