> > 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.
> I think this is the first revision to the mailet API (aside from v3
> changes) since its release many y
Danny Angus wrote:
Maybe the better solution is to put the mailet API on a separate release
schedule, so it's clear that James 2.1.x implements mailet API 1.0 and
James 2.2 implements mailet API 1.1.
Absolutely, the sooner we get round to miving it into its own cvs module the
happier I'll be.
Thoug
> Maybe the better solution is to put the mailet API on a separate release
> schedule, so it's clear that James 2.1.x implements mailet API 1.0 and
> James 2.2 implements mailet API 1.1.
Absolutely, the sooner we get round to miving it into its own cvs module the
happier I'll be.
Though as a guy w
> 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 w
Noel J. Bergman wrote:
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.
My notes below on the actual changes, but I think we need to discuss
changes before committing them to the mailet API
