Ben Webb wrote: > Daniel Russel wrote: > >>> I proposed creating the 'unstable' module to deal with (1). >>> >> I really don't see the point of that. Two things: >> - first, the traditional approach is to have stable and unstable >> branches in SVN. The advantage of this is that we don't have to change >> all the calls (by changing or removing the module) if we want to move >> stuff from one place to another. >> > > An SVN branch is just a directory anyway. And I'd rather not branch all > of IMP.
>> - second, given the structure of IMP, there is no reason to put unstable >> and stable classes in different directories. >> > > Perhaps we should not call this module 'unstable', because you seem to > be getting the wrong end of the stick here; perhaps 'misc' is a better > name. The intention is for it to be used for kernel additions that don't > happily sit anywhere else. Because the access is more open, it is likely > that people will put in unstable, untested code, but I certainly don't > think we should encourage that. > So to make the next iteration of the proposal: 1) the IMP kernel module is simplified to contain only the IMP kernel proper which is basically some subset of IMP/*.h, perhaps without decoratorbase and ParticleRefiner.
2) We add a module IMP_misc or IMP_core which contains all the existing restraints, states and decorators and stuff and has a more open access policy.
3) We adopt a convention of labelling things in IMP_misc as to their maturity. Perhaps "stable" for objects whose interfaces are unlikely to change and which are well tested and "unstable" for newer and less mature things and "unsupported" for things which are there because they may be of interest, but the level of interest is unclear and unless people say something they may not be actively developed.
4) IMP_misc will have an open commit policy, but convention that changes to the interface of things marked stable should be proceeded by a warning on imp-dev and that tests on them must not be broken.
I have a mostly marked version of the non-kernel imp code so I can easily produce the code for an IMP_misc module given a place to put it in SVN. Once it is in place, then we can remove the stuff from kernel.