[rules-dev] drools 5.5, 6.0 and roadmap => Which repo's get a 6.0 branch?

[Geoffrey De Smet]

> 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 list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev

-- 
With kind regards,
Geoffrey De Smet

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20120704/05bccbb4/attachment-0001.html