4:15 p.m.
Was just looking at some of the PRs and noticed that after a recent
change to Jacorb subsystem [1] we decided to bump the micro version of
that subsystem's management API [2]. What are the general guidelines
when it comes to bumping the management version of a subsystem? As far
as xsd changes are concerned, for EJB3, I've been making sure that the
version is bumped whenever there's a semantic change from a previous
released version. But I haven't so far touched the management version of
the EJB3 subsystem - in fact I had almost forgotten we had that. As a
specific example, I introduced a "default-security-domain" management
attribute for the EJB3 subsystem recently. Does this warrant a
management version bump?
[1] https://github.com/jbossas/jboss-as/pull/3175/files
[2] https://github.com/jbossas/jboss-as/pull/3197/files
-Jaikiran
12:16 a.m.
Hi,
a new version of mgmt model is required when change is incompatible with
previous model.
basically if you would take your current model and try to apply it to
previously released version of subsystem, would it work?
If no, then new version is required & transformers has to be written to
make sure compatibility in domain mode is preserved.
As for transformers go, I just started working on guide to help people out,
you can find it at
https://docs.jboss.org/author/display/AS72/Transformers(wip atm)
We agreed that version bump in master should be done only on major & minor
flags, micro version is reserved for 7.1/EAP branches.
in this concrete case, change was done to 7.1 branch and same one was
applied to master, hence master got just micro version bump, provided that
jacorb subsystem didn't have any other changes that are in 7.1 branch.
To go to details, change of that validator also changed the model, where
min-value was now different this would cause model that worked on new
definition could fail on old one.
--
tomaz
On Sat, Oct 6, 2012 at 4:15 PM, Jaikiran Pai <jpai(a)redhat.com> wrote:
Was just looking at some of the PRs and noticed that after a recent
change to Jacorb subsystem [1] we decided to bump the micro version of
that subsystem's management API [2]. What are the general guidelines
when it comes to bumping the management version of a subsystem? As far
as xsd changes are concerned, for EJB3, I've been making sure that the
version is bumped whenever there's a semantic change from a previous
released version. But I haven't so far touched the management version of
the EJB3 subsystem - in fact I had almost forgotten we had that. As a
specific example, I introduced a "default-security-domain" management
attribute for the EJB3 subsystem recently. Does this warrant a
management version bump?
[1] https://github.com/jbossas/jboss-as/pull/3175/files
[2] https://github.com/jbossas/jboss-as/pull/3197/files
-Jaikiran
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
4:50 p.m.
On 10/7/12 5:16 PM, Tomaž Cerar wrote:
Hi,
a new version of mgmt model is required when change is incompatible with
previous model.
basically if you would take your current model and try to apply it to
previously released version of subsystem, would it work?
If no, then new version is required & transformers has to be written to
make sure compatibility in domain mode is preserved.
Note that transformation only needs to be done if it can actually do
something useful. For example, the jacorb change made "0" a valid value
for some attribute. If a config includes that new value, a slave running
the old version won't be able to deal with that "0" and it's also not
correct to transform it into a "1". So the slave will just have to
ignore that profile, or if that's not possible the slave will have to be
upgraded before a config with "0" can be applied.
Tomaz had the good idea of recording these kinds of issues on the master
HC and making them visible through the management API so even if the
slave is ignoring the resource, admins could still find out what the
compatibility issues are. When we implement that some day I suspect
using a transformer to record the information but do nothing else will
be how it gets implemented.
As for transformers go, I just started working on guide to help
people
out, you can find it at
https://docs.jboss.org/author/display/AS72/Transformers (wip atm)
We agreed that version bump in master should be done only on major &
minor flags, micro version is reserved for 7.1/EAP branches.
in this concrete case, change was done to 7.1 branch and same one was
applied to master, hence master got just micro version bump, provided
that jacorb subsystem didn't have any other changes that are in 7.1 branch.
To go to details, change of that validator also changed the model, where
min-value was now different this would cause model that worked on new
definition could fail on old one.
--
tomaz
On Sat, Oct 6, 2012 at 4:15 PM, Jaikiran Pai <jpai(a)redhat.com
<mailto:jpai@redhat.com>> wrote:
Was just looking at some of the PRs and noticed that after a recent
change to Jacorb subsystem [1] we decided to bump the micro version of
that subsystem's management API [2]. What are the general guidelines
when it comes to bumping the management version of a subsystem? As far
as xsd changes are concerned, for EJB3, I've been making sure that the
version is bumped whenever there's a semantic change from a previous
released version. But I haven't so far touched the management version of
the EJB3 subsystem - in fact I had almost forgotten we had that. As a
specific example, I introduced a "default-security-domain" management
attribute for the EJB3 subsystem recently. Does this warrant a
management version bump?
[1] https://github.com/jbossas/jboss-as/pull/3175/files
[2] https://github.com/jbossas/jboss-as/pull/3197/files
-Jaikiran
_______________________________________________
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
_______________________________________________
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
4224
days inactive
4226
days old
2 comments
3 participants
participants (3)
-
Brian Stansberry -
Jaikiran Pai -
Tomaž Cerar