The Case for NxBRE v3

I am about to launch a complete refactoring of NxBRE, which will be done under version number 3. I have already prepared the Subversion repository for that matter: instead of branching, I have created different sub-folders in the trunk, this to reflect that v2 and v3 will not be branches but parallel projects.

At this point of your reading, I can hear you guys, NxBRE users in particular and software developers in general, saying: "Ohmigod, he is about to go the Netscape way and do one of the things you should never do"!

Please rest assured that I will not fall into this pitfall (but maybe in other ones!): this will not be a complete rewrite, not even an incomplete one. If you browse the feature requests for group "NxBRE3", you will see that this refactoring is mainly about:

• Refactoring the API, ie reorganizing files and folders, making namespaces more .NET flavored, substituting implementations with interfaces (this is mainly inspired by Joshua Bloch's reflections on APIs design),

• Switching to .NET 2.0 and SharpDevelop 2.0,

• Improving peripheral features like configuration and logging.

No new feature will be added to v3.0 so the same test suite will be used to validate that the new version has remained functionally equivalent.

The new version will break the ascending compatibility, which means that users of NxBRE will have to modify their code. This said, class names will not change so the impact should be limited to modify using clauses.

This refactoring will make NxBRE more palatable to new users and well-oriented for upcoming new features (like support for RuleML 1.0). It should have been done earlier, in fact, even before the very first release, right after converting JxBRE to .NET. This means that I was much less wiser three years ago!

Of course, no deadline has been set... After all, this is open source! Just kidding... I want things to be well done so version 3.0 will be cut when everybody will be happy with what they will see in the trunk!