[jboss-as7-dev] Subsystem model version for AS8
Scott Marlow
smarlow at redhat.com
Tue Mar 5 13:45:25 EST 2013
On 03/05/2013 10:55 AM, Jaikiran Pai wrote:
> 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.
Do we have any external projects that currently do any AS testing from
their testsuites (perhaps building AS7/AS8 from git repo source) and
kicking off Arquillian tests? I assume you meant that you would test
EJB invocations between AS7/AS8 manually but am also wondering what is
possible for test automation.
>
> -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
>
> _______________________________________________
> 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