[jboss-as7-dev] Subsystem model version for AS8
Paul Ferraro
paul.ferraro at redhat.com
Mon Mar 4 10:02:36 EST 2013
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
>
More information about the jboss-as7-dev
mailing list