On 7/31/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: > > i would prefer the storage/config compatibility issue to be managed by > > experimental modules. this means that people can code whatever new > > features without having to wait for some future next-major to be cut. > > I read this as 3.0 *will* *be* backward compatible. If any backward > incompatibility is introduced it must be introduced as experimental > module: am I understanding your words right?
perhaps 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 > 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. 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. i do accept that some forking of some functional modules will be necessary but IMO this is good since it allows new approaches to be developed whilst retaining the more mature code > That said I'm fine with this (I'm fine with almost anything that will > give JAMES Server an early release): I just would like to know if OTHERS > are also fine with this. I hope they will explain this while voting the > 3.0, or otherwise I hope someone will take care of understanding this in > the near future. IMHO this is a bridge that should be crossed we come to it 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. > >> In fact I think it should be better to define what to release and then > >> define the number to use, but I'm fine with *any* number as long as it > >> doesn't affect releasing asap (trivia: the trunk in 2004 was named 3.0). > >> I would like to know if the goal to keep storage/config.xml > >> compatibility is a priority in the 3.0 or not: IMHO this is the only > >> important thing to be able to dedice what can be included in trunk and > >> what will have to wait for trunk to become a branch. > > > > i think that it helps to have a good name for a distant collective goal > > > > - robert > > I completely agree. next-* labels were simple temporary workarounds, > waiting for this vote (in fact they was supposed to disappear on > dec2006/jan2007 but things screwed up). > > What I don't like is that we vote on 3.0 without having some sort of > agreement/understanding on what kind of changes we expect to accept in > trunk and what instead we expect to not accept in trunk so this kind of > vote would scary me as hell if I was still active and working on > message/envelope refactoring and repositories refactoring ;-) hopefully we might be able to tempt you back into active development one day soon ;-) this is just a label change 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. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
