> > Considering they were already deprecated in the previous > release IMHO > > we can safely remove all of them: do you agree? > > No. We have many users out there who customize JAMES and who > have their own matchers/mailets, and we only know the tip of > the iceberg. We should consider removing deprecated methods > when we (a) have published a replacement, and (b) have a > major version change, e.g., version 2 to version 3.
So I can safely do that for methods deprecated in 1.x releases and add a comment to every other deprecated methods so that we don't forget to remove them for the 3.0 release. If we see that we have many of them we could consider jumping to 3.0 instead of trying to release this 2.3.0. IMHO if we want to release a 2.3.0 we should try to do it NOW, or even better on a release of a few weeks ago (before the block assembly refactoring). BTW there is no version/release versioning explanation on the websites saying that only major releases will change the APIs and IIRC from 2.1 to 2.2 Mailet APIs have been changed by also removing methods/classes. My vote goes for 2.3.0 at the end of this refactoring and for API changes with removed methods, but I'm not against any other release cycle. When you or another pmc will start doing the release manager for the next release I'll look at the release proposal. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
