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

Wed Jul 4 03:37:06 EDT 2012

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.spam at 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 at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> --
> With kind regards,
> Geoffrey De Smet
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at 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 -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20120704/5e3d7d78/attachment.html 