> Amusingly, you replied to his commit message for the main branch, but that > doesn't change the thrust of your argument, since he also committed to the > v2 branch. :-)
Doh! :-) > Is there is change that you would want to make to the proposed API, or are > you raising a procedural issue? I would like to see the functionality > integrated. Procedural. What I'd like to see is this.. somewhere on the website & docs.. "James 2.whatever includes version 2.1.0 of the Mailet API, this version includes previews of some compatible changes proposed for inclusion in Mailet v3. Mailet v2.1.0 is wholly backwards compatible with Mailet v2.0 however Mailets written to take advantage of the new features will not be backwards compatible with Mailet v2.0" And a Mailet changes file, and javadoc comments highlighting the new methods. I think we also have to document whatever incompatibility exists between Mail storage in James, and an upgrade path. > IMO, deprecating setSender/getSender ought to be done. +1 if done with plenty of public documentation (changes file) > It isn't as if > building James v2 doesn't already involve deprecated methods from Avalon. > And in our case, we would do it properly, which means we document the new > calls, and we keep the old ones. If we know that we will be deprecating a > method, I think that we should do it. Deprecation is about > advanced warning > and better practice. Agreed. > As for Mail Attributes, I also think that we should do them. Yeah I agree with that much. We should ensure it doesn't surprise anyone is all. > I'm fine with reving the version to Mailet API v2.something or some other > procedural change. That's similar to why we've proposed calling the next > version 2.2.0, instead of 2.1.4. Very good, we're on the same wavelength then. d. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
