[wildfly-dev] Management Parser Versioning

[Jason Greene]

Yes, we don’t need to have bug-for-bug validation forward compatibility. We should only guarantee compatibility for the version as it was written.

> On Apr 23, 2015, at 10:32 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> I don't think I've ever rejected or even questioned a PR because it made 
> a parser tolerant in the way you describe, so I'm fine with being tolerant.
> 
> My only caveat is in no way do we have any commitment to be tolerant. If 
> a change is implemented in such a way that the legacy schema parsing is 
> tolerant, then it's tolerant for that change. Some other change may not 
> be implemented that way and the parsing won't be tolerant. So we'll be 
> inconsistent.
> 
> I'm sure we're already inconsistent in this regard, so that doesn't 
> worry me. The schema defines the rules. If you follow them, you know 
> what you'll get. If you break them, maybe it will work anyway, maybe 
> not. Our only guarantee if you break the rules is you'll either end up 
> with a valid running configuration or we'll fail.
> 
> On 4/23/15 10:17 AM, Darran Lofthouse wrote:
>> Thinking about future XML changes, once the parser is forked I think we
>> can also relax how we add new optional attributes and elements to the
>> schema.
>> 
>> As I see it our main commitment is: -
>> 
>> * XML that is valid according to the schema should parse without error. *
>> 
>> I say 'should' as I believe in some cases documentation is relied upon
>> to describe valid combinations.
>> 
>> * The XML we write must be valid according to the schema. *
>> 
>> Don't see any justification for not following that one.
>> 
>> * Parsers can be tolerant to XML that is technically invalid. *
>> 
>> e.g. we are not big on enforcing sequence ordering.
>> 
>> So lets say we have a release that contains a 4.0 version of the schema
>> I think if in version 4.1 of the schema we add an optional attribute or
>> element we can just add support for that attribute or element to the
>> existing parse method.
>> 
>> Of course if the new attribute or element is required then we will need
>> to switch to something version specific to avoid rejecting previously
>> valid configuration.
>> 
>> I know this is a long way off but I only raise this now as I realise
>> this has already happened where a new optional element has been added to
>> the schema.  Technically if we were strict about it the code is wrong
>> but the scenarios where it is going to break for someone are quite
>> contrived and I think this fits with tolerant parsing and we will
>> automatically fix on the next write.
>> 
>> Regards,
>> Darran Lofthouse.
>> 
>> 
>> On 22/04/15 13:30, Brian Stansberry wrote:
>>> That's fine with me.
>>> 
>>> On 4/22/15 6:20 AM, Darran Lofthouse wrote:
>>>> Working with the parsers for the core config has become increasingly
>>>> cryptic, we are now at the point where we have three different major
>>>> versions which diverge and converge as we work on them.  Most recent
>>>> changes have resulted in large sections of the config converging for 1.x
>>>> and 3.x leaving 2.x independent.
>>>> 
>>>> So that I can add references to Elytron I am starting to add support for
>>>> version 4.
>>>> 
>>>> One think that I have learned is that each major version tends to belong
>>>> to one branch of the codebase, all changes to that version happen on
>>>> that branch first: -
>>>> 
>>>>     1.x - Maintained only for EAP
>>>>     2.x - WildFly 8.x branch
>>>>     3.x - WildFly Core master branch
>>>> 
>>>> I would expect if further changes are made to core for WildFly 9
>>>> releases we will end up with 1.x branch of core and and 4.x version of
>>>> the schema will be owned by the master branch.
>>>> 
>>>> To make things less cryptic I am proposing that until we find a better
>>>> solution for all subsequent major schema versions we just fork the
>>>> parser and all related classes.
>>>> 
>>>> This will simplify the code being modified for the upstream development.
>>>> 
>>>> Forward porting parsing changes will also become a simple copy and paste.
>>>> 
>>>> For the current cryptic approach I think almost every engineer (and I am
>>>> finding it really hard to think of exceptions) that has worked in-depth
>>>> in this area has introduced at least one bug and I don't think the test
>>>> coverage is high enough to protect against this.
>>>> 
>>>> Regards,
>>>> Darran Lofthouse.
>>>> 
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>> 
>>> 
>>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
> 
> 
> -- 
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat