7:11 a.m.
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
8 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
9:24 a.m.
What about XSD schemas?
probably same rule?
On Mon, Feb 25, 2013 at 3:00 PM, Brian Stansberry <
brian.stansberry(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
9:30 a.m.
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(a)redhat.com <mailto:brian.stansberry@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(a)lists.jboss.org <mailto:jboss-as7-dev@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(a)lists.jboss.org <mailto:jboss-as7-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
7:10 p.m.
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(a)redhat.com>
To: "Tomaž Cerar" <tomaz.cerar(a)gmail.com>
Cc: "JBoss AS7 Development" <jboss-as7-dev(a)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(a)redhat.com <mailto:brian.stansberry@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(a)lists.jboss.org
> > <mailto:jboss-as7-dev@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(a)lists.jboss.org
> <mailto:jboss-as7-dev@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
7:23 p.m.
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(a)redhat.com>
> To: "Tomaž Cerar" <tomaz.cerar(a)gmail.com>
> Cc: "JBoss AS7 Development" <jboss-as7-dev(a)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(a)redhat.com <mailto:brian.stansberry@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(a)lists.jboss.org
>> > <mailto:jboss-as7-dev@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(a)lists.jboss.org
>> <mailto:jboss-as7-dev@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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
4:52 a.m.
ATM I think we cannot start doing transformers for 2.x model versions.
If nothing else we are missing baseline support for them (legacy .dmr
files, artifacts in maven)
but after that is satisfied there are not more barriers stopping us from
doing that.
But I think Paul's question is more in line of what we discussed on call on
how to go on with as8 vs eap.
--
tomaz
On Thu, Feb 28, 2013 at 2:23 AM, Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
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(a)redhat.com>
>> To: "Tomaž Cerar" <tomaz.cerar(a)gmail.com>
>> Cc: "JBoss AS7 Development" <jboss-as7-dev(a)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(a)redhat.com
<mailto:brian.stansberry@**redhat.com<brian.stansberry@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(a)lists.jboss.org
>>> >
<mailto:jboss-as7-dev@lists.**jboss.org<jboss-as7-dev@lists.jboss.org>
>>> >
>>> >
https://lists.jboss.org/**mailman/listinfo/jboss-as7-dev<https://lists...
>>> >
>>>
>>>
>>> --
>>> Brian Stansberry
>>> Principal Software Engineer
>>> JBoss by Red Hat
>>> ______________________________**_________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev(a)lists.jboss.org
>>>
<mailto:jboss-as7-dev@lists.**jboss.org<jboss-as7-dev@lists.jboss.org>
>>> >
>>>
https://lists.jboss.org/**mailman/listinfo/jboss-as7-dev<https://lists...
>>>
>>>
>>>
>>
>> --
>> Brian Stansberry
>> Principal Software Engineer
>> JBoss by Red Hat
>> ______________________________**_________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>>
https://lists.jboss.org/**mailman/listinfo/jboss-as7-dev<https://lists...
>>
>
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
12:19 p.m.
Right. So I'm interested in what the specific problems are expected to
be with the clustering subsystems.
On 2/28/13 4:52 AM, Tomaž Cerar wrote:
ATM I think we cannot start doing transformers for 2.x model
versions.
If nothing else we are missing baseline support for them (legacy .dmr
files, artifacts in maven)
but after that is satisfied there are not more barriers stopping us from
doing that.
But I think Paul's question is more in line of what we discussed on call
on how to go on with as8 vs eap.
--
tomaz
On Thu, Feb 28, 2013 at 2:23 AM, Brian Stansberry
<brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>> wrote:
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(a)redhat.com
<mailto:brian.stansberry@redhat.com>>
To: "Tomaž Cerar" <tomaz.cerar(a)gmail.com
<mailto:tomaz.cerar@gmail.com>>
Cc: "JBoss AS7 Development" <jboss-as7-dev(a)lists.jboss.org
<mailto:jboss-as7-dev@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(a)redhat.com
<mailto:brian.stansberry@redhat.com>
<mailto:brian.stansberry@__redhat.com
<mailto:brian.stansberry@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(a)lists.jboss.org
<mailto:jboss-as7-dev@lists.jboss.org>
> <mailto:jboss-as7-dev@lists.__jboss.org
<mailto:jboss-as7-dev@lists.jboss.org>>
>
https://lists.jboss.org/__mailman/listinfo/jboss-as7-dev
<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(a)lists.jboss.org
<mailto:jboss-as7-dev@lists.jboss.org>
<mailto:jboss-as7-dev@lists.__jboss.org
<mailto:jboss-as7-dev@lists.jboss.org>>
https://lists.jboss.org/__mailman/listinfo/jboss-as7-dev
<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(a)lists.jboss.org
<mailto:jboss-as7-dev@lists.jboss.org>
https://lists.jboss.org/__mailman/listinfo/jboss-as7-dev
<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
9:02 a.m.
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(a)redhat.com>
To: "Paul Ferraro" <paul.ferraro(a)redhat.com>
Cc: "JBoss AS7 Development" <jboss-as7-dev(a)lists.jboss.org>, "Tomaž
Cerar" <tomaz.cerar(a)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(a)redhat.com>
>> To: "Tomaž Cerar" <tomaz.cerar(a)gmail.com>
>> Cc: "JBoss AS7 Development" <jboss-as7-dev(a)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(a)redhat.com
>>> <mailto:brian.stansberry@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(a)lists.jboss.org
>>> > <mailto:jboss-as7-dev@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(a)lists.jboss.org
>>> <mailto:jboss-as7-dev@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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
12:38 p.m.
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(a)redhat.com>
> To: "Paul Ferraro" <paul.ferraro(a)redhat.com>
> Cc: "JBoss AS7 Development" <jboss-as7-dev(a)lists.jboss.org>,
"Tomaž Cerar" <tomaz.cerar(a)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(a)redhat.com>
>>> To: "Tomaž Cerar" <tomaz.cerar(a)gmail.com>
>>> Cc: "JBoss AS7 Development" <jboss-as7-dev(a)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(a)redhat.com
>>>> <mailto:brian.stansberry@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(a)lists.jboss.org
>>>> > <mailto:jboss-as7-dev@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(a)lists.jboss.org
>>>> <mailto:jboss-as7-dev@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(a)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
12:51 p.m.
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(a)redhat.com>
>> To: "Paul Ferraro" <paul.ferraro(a)redhat.com>
>> Cc: "JBoss AS7 Development" <jboss-as7-dev(a)lists.jboss.org>,
"Tomaž Cerar" <tomaz.cerar(a)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(a)redhat.com>
>>>> To: "Tomaž Cerar" <tomaz.cerar(a)gmail.com>
>>>> Cc: "JBoss AS7 Development"
<jboss-as7-dev(a)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(a)redhat.com
>>>>> <mailto:brian.stansberry@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(a)lists.jboss.org
>>>>> > <mailto:jboss-as7-dev@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(a)lists.jboss.org
>>>>> <mailto:jboss-as7-dev@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(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>> --
>> Brian Stansberry
>> Principal Software Engineer
>> JBoss by Red Hat
>>
--
- DML
9:52 a.m.
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(a)redhat.com>
To: jboss-as7-dev(a)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(a)redhat.com>
>>> To: "Paul Ferraro" <paul.ferraro(a)redhat.com>
>>> Cc: "JBoss AS7 Development"
<jboss-as7-dev(a)lists.jboss.org>,
>>> "Tomaž Cerar" <tomaz.cerar(a)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(a)redhat.com>
>>>>> To: "Tomaž Cerar" <tomaz.cerar(a)gmail.com>
>>>>> Cc: "JBoss AS7 Development"
<jboss-as7-dev(a)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(a)redhat.com
>>>>>> <mailto:brian.stansberry@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(a)lists.jboss.org
>>>>>> > <mailto:jboss-as7-dev@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(a)lists.jboss.org
>>>>>> <mailto:jboss-as7-dev@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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
9:55 a.m.
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(a)redhat.com>
> To: jboss-as7-dev(a)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(a)redhat.com>
>>>> To: "Paul Ferraro" <paul.ferraro(a)redhat.com>
>>>> Cc: "JBoss AS7 Development"
<jboss-as7-dev(a)lists.jboss.org>,
>>>> "Tomaž Cerar" <tomaz.cerar(a)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(a)redhat.com>
>>>>>> To: "Tomaž Cerar" <tomaz.cerar(a)gmail.com>
>>>>>> Cc: "JBoss AS7 Development"
<jboss-as7-dev(a)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(a)redhat.com
>>>>>>> <mailto:brian.stansberry@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(a)lists.jboss.org
>>>>>>> > <mailto:jboss-as7-dev@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(a)lists.jboss.org
>>>>>>> <mailto:jboss-as7-dev@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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
12:45 p.m.
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(a)redhat.com>
>> To: jboss-as7-dev(a)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(a)redhat.com>
>>>>> To: "Paul Ferraro" <paul.ferraro(a)redhat.com>
>>>>> Cc: "JBoss AS7 Development"
<jboss-as7-dev(a)lists.jboss.org>,
>>>>> "Tomaž Cerar" <tomaz.cerar(a)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(a)redhat.com>
>>>>>>> To: "Tomaž Cerar" <tomaz.cerar(a)gmail.com>
>>>>>>> Cc: "JBoss AS7 Development"
<jboss-as7-dev(a)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(a)redhat.com
>>>>>>>> <mailto:brian.stansberry@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(a)lists.jboss.org
>>>>>>>> >
<mailto:jboss-as7-dev@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(a)lists.jboss.org
>>>>>>>> <mailto:jboss-as7-dev@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(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
1:29 p.m.
We have the testsuite/mixed-domain module which is currently quite empty but which tests
like this could be added to
On 5 Mar 2013, at 18:45, Scott Marlow wrote:
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(a)redhat.com>
>>> To: jboss-as7-dev(a)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(a)redhat.com>
>>>>>> To: "Paul Ferraro" <paul.ferraro(a)redhat.com>
>>>>>> Cc: "JBoss AS7 Development"
<jboss-as7-dev(a)lists.jboss.org>,
>>>>>> "Tomaž Cerar" <tomaz.cerar(a)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(a)redhat.com>
>>>>>>>> To: "Tomaž Cerar"
<tomaz.cerar(a)gmail.com>
>>>>>>>> Cc: "JBoss AS7 Development"
<jboss-as7-dev(a)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(a)redhat.com
>>>>>>>>> <mailto:brian.stansberry@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(a)lists.jboss.org
>>>>>>>>>> <mailto:jboss-as7-dev@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(a)lists.jboss.org
>>>>>>>>> <mailto:jboss-as7-dev@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(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
---------------------------------------
Kabir Khan
Prinicipal Software Engineer
JBoss by Red Hat
10:02 a.m.
I believe there is currently a gap, because JNDI seems to be missing.
Andy
----- Original Message -----
From: "Jim Tyrrell" <jtyrrell(a)redhat.com>
To: "Andrig Miller" <anmiller(a)redhat.com>
Cc: "David M. Lloyd" <david.lloyd(a)redhat.com>,
jboss-as7-dev(a)lists.jboss.org
Sent: Tuesday, March 5, 2013 9:01:09 AM
Subject: Re: [jboss-as7-dev] Subsystem model version for AS8
> 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.
Andy,
Has this been tested with EAP 5.x and EAP 6.x?
Thank You
Jim Tyrrell
4326
days inactive
4334
days old
16 comments
9 participants
participants (9)
-
Andrig Miller -
Brian Stansberry -
David M. Lloyd -
Jaikiran Pai -
Jim Tyrrell -
Kabir Khan -
Paul Ferraro -
Scott Marlow -
Tomaž Cerar