Robert Burrell Donkin ha scritto: > in terms of storage/configuration compatibility: > > 1 i don't believe that a decision needs to be taken now and would be > better taken later against a concrete proposal > 2 i believe that development on most proposals could be done without > the need to break storage/configuration compatibility. this may mean > forking some modules and decoupling more parts of the system. > 3 i would prefer to see 3.0 storage/configuration compatible by > default but users able to choose new, incompatible solutions > 4 i would prefer to see more development on trunk and less on branches
I agree on #1, #3 and #4. I'm not on the same line about #2, but given we agree on #1 we can ignore this. >> 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. - One is the Message/Envelope change and the refactoring of mail/spool repositories interfaces: again there is many code bound to this interfaces. - 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]. - 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. > the next step in the modularisation needs to be factoring out features > from the core into API, library and functions. with a little bit of > luck and some refactoring, i hope that core module can be eliminated. +1 > 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 :-) > no plan is necessary at this time. planning in the abstract has a > tendency to lead to unnecessary friction. when someone has a concrete > proposal that really requires breaking storage/configuration > compatibility then we can decide what to do at that time. In past friction has been created by concrete plans and not by abstract things (I can provide links to threads if you are interested in the social analysis). While things remained abstract enough everyone was happy to dream about his own idea of real "implementation". Concreteness, here, led to friction. But this is past, and shit happens. Stefano PS: sorry for having hijacked the vote topic. I won't do this anymore.. or at least I'll try ;-) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
