Thank you very much for the reply, Alex. I totally agree with user communication and gradual approach.
Btw, "Strict mode" and "legacy mode" likely don't fit well with the parser architecture. One parser implementation is tied to one LanguageLevelOption. In the current codebase, The new parser -> DRL6 The old DRL6 parser -> DRL6 The old DRL6_STRICT parser -> DRL6_STRICT The old DRL5 parser -> DRL5 (Sorry, I haven't mentioned the old DRL6_STRICT/DRL5 parsers before, but they exist) But the proposal is The new parser -> DRL10 The old DRL6 parser -> DRL6 The old DRL6_STRICT parser -> DRL6_STRICT The old DRL5 parser -> DRL5 and considering the migration plan. You seem to assume that the new parser can handle all DRL5, DRL6 and DRL10. But it can't. The new parser (DRL10) is itself "strict mode" and the old DRL6 parser is itself "legacy mode". Users can choose any parser as long as they exist. So the point is how we will provide warnings. 1. Introduce the new parser(DRL10), but make it optional (not enabled by default). 2. Raise warnings when the syntax to be dropped are used **in the old DRL6 parser**, saying these syntax are deprecated. Raise warnings when DRL5 and DRL6_STRICT are used, saying these language levels are deprecated. <six months later> 3. Raise warnings when DRL6 is used, saying DRL10 will be the default in the future <six months later> 4. Make the new parser(DRL10) default <xxx months later> 5. In the next major release (version 11), drop the old DRL5 and DRL6_STRICT parsers <xxx months later> 6. In the major release after that (version 12), drop the old DRL6 parser, it means the deprecated syntax cannot be used at this point. How does it sound? Additional points: Until step 3, probably most community users are not aware of the new parser(DRL10) even if documented. We may promote it in the community and collect feedback. > Additionally, I think eval should be handled differently. It needs its > own thread and likely more discussion, as well as a clear and careful > communication plan for its deprecation. Agreed. > Finally, I’d recommend including a migration tool as part of this plan > to help users transition more smoothly. Agreed. Regards, Toshiya On Tue, Nov 12, 2024 at 9:41 PM Alex Porcelli <a...@porcelli.me> wrote: > Thank you, Toshyia for the proposal! > > I have a concern about making these changes without the proper > communication channels in place. We agreed a while back to focus on > the release first and address communication afterward. > > Once the communication plan is sorted out, I suggest a more gradual > approach to introduce the new parser: > > - First, introduce the new parser, but make it optional (not enabled > by default). Start by showing warnings for any syntax that will be > removed, including v5 syntax. > - About six months later, add warnings for users not yet using the new > parser, and introduce a "strict mode" (which won’t be enabled by > default). > - Another six months later, set the new parser as the default. > - Enable strict mode by default. > - In the next major release (version 11), adopt the new parser as the > default and remove old syntaxes. Add a "legacy mode" to support older > syntaxes, with warnings for their use, and drop v5 syntax. > - In the major release after that (version 12), completely remove all > old syntaxes. > > Additionally, I think eval should be handled differently. It needs its > own thread and likely more discussion, as well as a clear and careful > communication plan for its deprecation. > > Finally, I’d recommend including a migration tool as part of this plan > to help users transition more smoothly. > > Alex > > On Tue, Nov 12, 2024 at 12:26 AM Toshiya Kobayashi > <toshiyakobaya...@gmail.com> wrote: > > > > Hello, > > > > We have merged a new Antlr4 based DRL parser in the drools main branch. > > It's not enabled by default, so it doesn't affect users now. > > > > The new parser has been focused on backward compatibility and existing > unit > > tests are all green with it. > > > > However, at this point, we can take an opportunity to "slim down DRL > > syntax" in order to improve the future maintainability of drools. > > > > PROPOSAL is > > > > - Drop or modify some DRL syntax, which cause maintenance cost and/or > > ambiguity and/or are less useful. > > - Introduce LanguageLevelOption.DRL10 for the new syntax. Enabled when > > configured. It is handled by the new parser. > > - Announce "deprecate" for the dropped syntax, so that users can migrate > to > > DRL10. > > - At some point in the future, make LanguageLevelOption.DRL10 default. > > (Still keep DRL6 and the old parser as a transition period) > > - When we consider the new parser is mature, we will remove DRL6 and the > > old parser > > > > Further details and candidates syntax to drop are written in this docs. > > > > > https://docs.google.com/document/d/1Ibmj-koAMbeaungHuFeQtw2zD03YJcNJkJ-kdN8ugks/edit?usp=sharing > > > > Feel free to add comments on the docs. Discussing this on the thread is > > also great. > > > > Thanks! > > Toshiya > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > For additional commands, e-mail: dev-h...@kie.apache.org > >
