Peter, I don't want to sound patronizing or "besser-wisser", but I disagree with your ambitions.
Major releases are an opportunity, where "clean up" should occur but happen as seldom as possible. Constraining such opportunity causes long-term maintenance head-aches for the community which might drain it of the little energy that exists, IMHO pretty much the current state of River. Now, if you formalizes your list of what is possible, I think we can devise strategy on how to make such changes without breaking source compatibility as well. This is something I was notoriouisly a PITA among co-workers about 20-25 years ago. I called it designing for "forward compatibility", the art of removing future obstacles of being backward compatibility. One such product (RTOS) released 2.0 in 1986 and is still in its 2.x series. Such is not "automatic" and can not be bolted on afterwards in a compatible manner, but if River allows itself to break compatibility for a 3.0 release with such forward-thinking mindset you have, then I think it can be possible to not break compatibility for decades. If I don't make sense, just ignore me, and I'll keep my advice to myself. -- Niclas On Oct 1, 2009 7:24 PM, "Peter Firmstone" <[email protected]> wrote: Niclas Hedhman wrote: > > On Thu, Oct 1, 2009 at 9:20 AM, Peter Firmstone < [email protected]> wrote: ... Less than desirable. A fork perhaps? Just kidding... But it's not out of the question, it really depends upon the trade off, ie; what we gain. It isn't something that is prohibited, just to be carefully considered. A Major Release doesn't need to break source code compatibility to be a major release, however if such an occurrence eventuates, it's not unreasonable to expect application developers to make some changes before compiling and distribution. If it is possible not to break binary compatibility while gaining a great new feature, then shouldn't we keep that option available? This enables users of the platform to upgrade while allowing existing application implementations to prevail. The significance comes from River being a Platform much like Java is a platform. For instance the following Changes Break Source code compatibility but not binary compatibility: Adding new methods to existing Interfaces, you could simply extend the old interface by creating a new interface, however being able to provide the same service interface to both old and new bytecode is advantageous. (Especially when old objects might gain new life from new bytecode... bear with me...) In a Class designed for inheritance, for instance, one might need to increase the visibility of one of its methods, ie public from protected. A subclass in an Application that overrides this method with protected access and has other classes within itself that utilise the overridden behaviour would no longer compile due to this change, however binary compatibility hasn't been broken. Changes to the throws clause of a method or constructor doesn't change binary compatibility. Additional overloading of existing methods or constructors in classes or interfaces doesn't break binary compatibility. The use case would be that we realise that in order to have the excellent new feature X, that we must break compile time compatibility. But since binary compatibility is more flexible than compile time, we might be able to salvage binary compatibility and avoid inconveniencing users who don't have the ability to rewrite and recompile their application code. The lock-in characteristic of old software platform binary applications is the biggest obstacle in platform migration. Tools to mitigate it somewhat when possible are a blessing. I must confess that I deliberately threw the comment about binary compatibility into the mix since it is of relevance to the codebase analysis service that I'm working on. Binary Compatibility flexibility allows a more natural evolution of class files, based on identification of forward binary compatible API, this is particularly relevant to long lived objects. Clients can receive new compatible class files for their old objects when they restart their jvm. River in its current form is not suitable for the semantic web, due to current code base limitations and ClassLoader issues. I want to make it so. Overly ambitious perhaps, however I've always relished a good challenge, without this aspect of my personality, I'd probably have little motivation to be active on this list. Such motivations have drawbacks too though. Cheers, Peter. > Personally, I think this requirement is too ambitious. If source > compatibility is broken, you ...
