On 7/31/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto:
<snip> > >> IMHO it worth specifying that this is not the panacea because this means > >> that backward incompatible changes in core stuff will not be supported > >> unless you clone all of the modules. > > > > that what you mean by core. an example would be useful. > > There are old refactorings that have been delayed forever because of > introduced incompatibilities. > - One of them is mailet api changes: when you change the mailet api you > probably need to change a lot of code in james. IMHO this is now a matter for the mailet subproject. once a new API has been agreed and released, then we can work out what to do about the server. > - One is the Message/Envelope change and the refactoring of mail/spool > repositories interfaces: again there is many code bound to this interfaces. i don't understand the proposal in detail. however, it's usually possible to preserve only storage/configuration compatibility (and not code binary compatibility) by add the new API as an extra interface but without knowing more about the proposal, i don't know whether it would be possible in this case. > - One is complete DNS support (requires changes in mailet api, in > smtpserver, in the spoolmanager and in the remote delivery) [trivia: I > joined JAMES mainly to add DSN support to it]. i don't understand why this would necessarily break storage/configuration compatibility > - probably there are many more I don't remember now. > > Btw, as you pointed out, maybe I'm too much worried about this as it > seems as no one have this issues in the roadmap anymore. that's because i'm very carefully not to propose a roadmap ;-) the road to 3.0 will lead to where ever people want it go > > dubbing trunk 3.0 (rather than next-major) does not include or exclude > > a commitment to maintaining backwards compatibility. it consists of > > nothing more or less than deciding to adopt a new label. when someone > > wants to make a change that is not backwards compatible then this is > > when we should make a decision. > > You "lead" this effort now, so let's play your game :-) i'm not leading anything :-) i'm just doing what seems right to me dubbing the trunk 3.0 seems a logical step right now so i proposed it - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
