We will develop 5.5 and 6.0 in parallel.
This covers drools
expert. Does it cover guvnor?
Given the list of repository, which get branched between 5.5 and 6.0
droolsjbpm-integration: only possible if jbpm is also branched
guvnor: no? Branching would not be practical (too much cherry picking).
droolsjbpm-tools: only possible if guvnor is also branched
drools-planner: no. Planner will work solely on the knowledge-api and
therefor need no branching
At some point, all these repo's will be branched between 5.5 and 6.0
(although jbpm and designer might have a different branch name),
but the question is which repo's will truly develop 5.5 and 6.0 in parallel.
Op 04-07-12 05:59, Mark Proctor schreef:
5.5 will remain JDK5 complaint. 6.0 will move to JDK6.
We will provide migration scripts from 5.x.
On 04/07/2012 04:32, Mark Proctor wrote:
> --- copied from blog article ---
> Some time soon we will branch master. The current master will be
> branched to 5.5 and then master will become 6.0.
> We will develop 5.5 and 6.0 in parallel. In general we will try to
> apply as many bug fixes and stable features to both branches, for as
> long as it's practically possible. At some point 6.0 will diverge too
> much and the cost will become too high.
> I hope we can release a 5.5 within the next 4-5 months; this may very
> depending on the impact of other commitments.
> 6.0 will be a longer term effort, and will involve the most drastic
> changes at both the engine and language level to date. The engine
> algorithm will be almost completely new, and will no longer be
> considered a Rete implementation. Instead it will be a lazy
> collection oriented matching algorithm, that will support adaptive
> network topologies. First we'll deliver the lazy matching algorithm
> and then shift to collection oriented. The adaptive network
> topologies will take more time and may deliver after 6.0. These
> engine changes will lay the ground work for exploiting multi-cpu
> architectures, and durable backing stores (Active Databases). I also
> hope we can integrate our engine with a tableaux algorithm, to
> provide seamless description logic capabilities for semantic
> ontologies; but that's still a very open research area, with many
> 6.0 will most likely retain api comparability (no current plans to
> break it), however the DRL syntax will be broken. DRL has been
> backwards compatible, excluding bugs and regressions, for almost 7
> years now. We plan to take this opportunity to revamp DRL, as we
> fully embrace becoming a hybrid reasoning engine. We will fully
> explore passive, reactive, relational and functional programming
> styles. The hope is we can create a declarative language system, more
> flexible and more suitable for a wider range of solutions. I also
> really want to address some of the usability problems associated with
> rule execution control, particularly around salience and the various
> rule groups (agenda-groups, ruleflow-groups, activation-groups).
> Relative salience and a single concept around a flexible RuleModule
> will hopefully make this possible. We have to start making things
> easier, simpler and more consistent.
> We are just starting to flesh out our designs, figuring out what
> works and what doesn't. All are at the very early stages, much has
> not yet been added, and everything is open to debate.
> General rule syntax
> The event sequencing draft can be found here:
> The functional programming aspects are still being explored on this
> wiki page:
> We will eventually roll the later two back in the Drools60 document,
> to provide a single document that covers the 6.0 language specific.
> The web based tooling is also under going a revamp. It will offer a
> more flexible workbench like experience where all panels are plugins,
> with support for perspectives. This will allow us to build a
> consistent and unified approach to our web tooling efforts across
> Drools&jBPM. We also have a mechanism now that will allow our web
> based components, such as decision tables and guided editors to be
> used in Eclipse -- to create a consistent experience between the two
> environments. We have back ported the java7 vfs api and have a Git
> implementation for this, we will also continue provide a JCR
> implementation. So far Git is looking extremely scalable and easy to
> use. JGit provides a full java implementation, making out of the box
> use easy. Stay tuned for more news. Hopefully in less then 2 months
> we will have some early proof of concepts to show, for the web based
> If you want to help make history happen, joins us on irc (real time
> chat). You can also leave comments on the wiki pages or the mailing
> lists (developer list).
> Here goes nothing!!!
rules-dev mailing list