[jboss-as7-dev] Subsystem model version for AS8
Andrig Miller
anmiller at redhat.com
Tue Mar 5 10:52:05 EST 2013
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
More information about the jboss-as7-dev
mailing list