[jboss-as7-dev] Subsystem model version for AS8
Jaikiran Pai
jpai at redhat.com
Tue Mar 5 10:55:36 EST 2013
I might be wrong, but I haven't seen tests for these in EAP6/AS7. Do we
have them somewhere? I do plan to add some for EJB invocations between
different AS versions of AS7/8.
-Jaikiran
On Tuesday 05 March 2013 09:22 PM, Andrig Miller wrote:
> I would too, and I would add something as well.
>
> For some customers, we have agreed to keep JMS clients compatible across three major releases. So, and EAP 5.x client should be able to work with EAP 6 and EAP 7.
>
> So, this means that not only the API has to be compatible, but the wire protocols have to continue to work. Things like JNDI usage for a JMS client has to continue to work.
>
> This is a big deal, and its in these customers contracts for their EAP subscriptions.
>
> Andy
>
> ----- Original Message -----
>> From: "David M. Lloyd" <david.lloyd at redhat.com>
>> To: jboss-as7-dev at lists.jboss.org
>> Sent: Monday, March 4, 2013 11:51:54 AM
>> Subject: Re: [jboss-as7-dev] Subsystem model version for AS8
>>
>> I agree with Brian 100% on all points, FWIW.
>>
>> On 03/04/2013 12:38 PM, Brian Stansberry wrote:
>>> 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
>>>>>
>>>
>>
>> --
>> - DML
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
More information about the jboss-as7-dev
mailing list