I would love to see that happening for jbpm as well. 5.4 and 6 in parallel On Wed, Jul 4, 2012 at 4:25 AM, Geoffrey De Smet <ge0ffrey.s...@gmail.com>wrote:
> ** > > 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 *early > on*? > > droolsjbpm-knowledge: yes? > drools: yes > jbpm: no? > 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 > process-designer: no > > 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. > > Mark > On 04/07/2012 04:32, Mark Proctor wrote: > > http://blog.athico.com/2012/07/drools-55-60-and-future.html > --- 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 unknowns. > > 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 > https://community.jboss.org/wiki/Drools60 > > The event sequencing draft can be found here: > https://community.jboss.org/wiki/EventSequencing > > The functional programming aspects are still being explored on this wiki > page: > https://community.jboss.org/wiki/FunctionalProgrammingInDrools > > 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 efforts. > > 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). > http://www.jboss.org/drools/irc > http://www.jboss.org/drools/lists > > Here goes nothing!!! > > Mark > > > > > _______________________________________________ > rules-dev mailing > listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev > > > -- > With kind regards, > Geoffrey De Smet > > > _______________________________________________ > rules-dev mailing list > rules-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > > -- - MyJourney @ http://salaboy.wordpress.com - Co-Founder @ http://www.jugargentina.org - Co-Founder @ http://www.jbug.com.ar - Salatino "Salaboy" Mauricio -
_______________________________________________ rules-dev mailing list rules-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev
