[jboss-as7-dev] Subsystem model version for AS8
Brian Stansberry
brian.stansberry at redhat.com
Mon Mar 4 13:38:11 EST 2013
I think continuing to address specific problems is important. For a
number of reasons:
1) The standards we're trying to set for backwards compatibility IMHO
need to keep increasing. My impression from discussions with the
business side people behind EAP is that they agree. At some point we're
going to need to be able to support some form of domain management
across major product versions. I'd rather we work incrementally toward
that by solving problems rather than punting and then have to figure out
all the problems when someone forces the requirement.
As an example, the current discussion on figuring out how to deal with
deleted subsystems like CMP is useful. Similarly, I think it will be
useful to figure out how to deal with a radical transition in a
subsystem, a la what might happen with the web subsystem. Clearly we
can't transform completely incompatible configs, but can both variations
co-exist in a domain, with legacy server-groups running legacy profiles
and other server groups running newer configs? That should be a solvable
problem.
2) I fully expect demands to port AS 8 features back into EAP 6. It's
going to happen. When it does, the compatibility requirement will
suddenly appear. Better to address it when the feature is written than
to expect people less familiar with the problem to add it during a port.
3) Transformation is a somewhat separate issue from backward
compatibility for management clients, but we've found that doing and
testing the transformation is real helpful in identifying client
compatibility problems. Client compatibility is real important. We've
promised many times that we won't willy-nilly break the client APIs even
across major versions, so we need some kind of enforcement that we're
not doing that.
4) I think the AS is going to be moving toward more rapid major
releases. If we use each of those as an opportunity to break
compatibility at will, our software will be uselessly unstable, and when
the time comes to restore some compatibility guarantees for EAP, the
task will be impossible.
I also hope that given we're two years into the life of our subsystems
that the "rapidly evolving" nature for most of their management APIs is
about at an end. That should have been the case a year ago. Obviously
there will always be new things getting added.
On 3/4/13 9:02 AM, Paul Ferraro wrote:
> It's not that there's a problem - it's just that we can't maintain backwards compatibility indefinitely, since the work required to do so grows exponentially (for rapidly evolving subsystems). A major version bump seems like a natural breaking point - otherwise, what is the significance of incrementing to 2.0?
> TBH - I mostly ask because I'm lazy and don't want to write transformers if I don't have to...
>
> Paul
>
> ----- Original Message -----
>> From: "Brian Stansberry" <brian.stansberry at redhat.com>
>> To: "Paul Ferraro" <paul.ferraro at redhat.com>
>> Cc: "JBoss AS7 Development" <jboss-as7-dev at lists.jboss.org>, "Tomaž Cerar" <tomaz.cerar at gmail.com>
>> Sent: Wednesday, February 27, 2013 8:23:26 PM
>> Subject: Re: [jboss-as7-dev] Subsystem model version for AS8
>>
>> What's the problem going to be?
>>
>> On 2/27/13 7:10 PM, Paul Ferraro wrote:
>>> Do the 2.x model versions need to be backwards compatible with 1.x
>>> versions?
>>> i.e. Do we need transformers to support a domain with mixed major
>>> versions?
>>> I hope not.
>>>
>>> ----- Original Message -----
>>>> From: "Brian Stansberry" <brian.stansberry at redhat.com>
>>>> To: "Tomaž Cerar" <tomaz.cerar at gmail.com>
>>>> Cc: "JBoss AS7 Development" <jboss-as7-dev at lists.jboss.org>
>>>> Sent: Monday, February 25, 2013 10:30:24 AM
>>>> Subject: Re: [jboss-as7-dev] Subsystem model version for AS8
>>>>
>>>> Yes.
>>>>
>>>> On 2/25/13 9:24 AM, Tomaž Cerar wrote:
>>>>> What about XSD schemas?
>>>>>
>>>>> probably same rule?
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Feb 25, 2013 at 3:00 PM, Brian Stansberry
>>>>> <brian.stansberry at redhat.com
>>>>> <mailto:brian.stansberry at redhat.com>>
>>>>> wrote:
>>>>>
>>>>> Yes, major version bump please. This makes it
>>>>> straightforward
>>>>> to avoid
>>>>> version conflicts with EAP 6.x. If EAP 6.x needs to change
>>>>> API
>>>>> in more
>>>>> than a bug fix way, they can use a minor version with no
>>>>> fear
>>>>> that
>>>>> community AS has already used that # for something else.
>>>>>
>>>>> On 2/25/13 7:11 AM, Tomaž Cerar wrote:
>>>>> > Hi,
>>>>> >
>>>>> > I remember few discussions on IRC in last weeks(s) about
>>>>> > how
>>>>> > to
>>>>> handle
>>>>> > version bumps for subsystem model when changes are done
>>>>> > on
>>>>> > AS8
>>>>> codebase.
>>>>> >
>>>>> > It was somewhat agreed that instead of bumping minor
>>>>> > version
>>>>> > we
>>>>> should
>>>>> > upgrade major version.
>>>>> >
>>>>> > aka instead of doing 1.2 --> 1.3, new version should be
>>>>> > 2.0
>>>>> >
>>>>> > That gives us flexibility of bumping minor version to 7.x
>>>>> > codebase if
>>>>> > need arises.
>>>>> >
>>>>> > I am writing this as there was some PRs lately that bump
>>>>> > just
>>>>> minor version.
>>>>> >
>>>>> > So, can we get an agreement of new versioning rules, that
>>>>> > we
>>>>> > will
>>>>> then
>>>>> > follow.
>>>>> >
>>>>> > I personalty favor major version bumps...
>>>>> >
>>>>> >
>>>>> > --
>>>>> > tomaz
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> > jboss-as7-dev mailing list
>>>>> > jboss-as7-dev at lists.jboss.org
>>>>> > <mailto:jboss-as7-dev at lists.jboss.org>
>>>>> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>> >
>>>>>
>>>>>
>>>>> --
>>>>> Brian Stansberry
>>>>> Principal Software Engineer
>>>>> JBoss by Red Hat
>>>>> _______________________________________________
>>>>> jboss-as7-dev mailing list
>>>>> jboss-as7-dev at lists.jboss.org
>>>>> <mailto:jboss-as7-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Principal Software Engineer
>>>> JBoss by Red Hat
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> jboss-as7-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>> --
>> Brian Stansberry
>> Principal Software Engineer
>> JBoss by Red Hat
>>
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
More information about the jboss-as7-dev
mailing list