Will 1.0.1 & 1.1 be incompatible with 1.0?

[Aaron Mulder <am...@alumni.princeton.edu>]

It seems like if we move ahead as planned for 1.0.1 and 1.1, we're
going to ship a product with configIds like
geronimo/j2ee-server/1.0.1/car, which means that many deployment plans
written for 1.0 will not be able to be deployed unmodified on 1.0 --
and it will instantly turn a huge number of published articles and
examples into errors (think of it -- any example including a Geronimo
configId will be wrong).  Furthermore, there's no way to write a plan
that will work on more than one specific major/minor/patch release of
Geronimo, if you have a dependency on a server plan other that the
default (such as depending on ActiveMQ or CORBA or whatever) or a
reference to a GBean in a Geronimo configuration other than your own
(such that the module's configId must appear in the reference, like,
say, ServerInfo).  I don't know why this hasn't bothered me up until
now, but I think it's a pretty serious problem.

I think we have a few options:

1) Ship 1.0.1 with all the configIds saying "1.0" so there is no issue
for at least that release

2) Remove version numbers from configIds from 1.0.1 onward, so at
least we can have backward compatibility from 1.0.1 forward

3) Put in some logic to treat all version numbers in configIds as wildcards

4) Support explicit wildcards or version ranges in configIds

My opinions on these are:

I think it would be workable to make all the configIds in 1.0.1 say
1.0, though it would surely be painful to change substitution
variables in ALL the plans accordingly.  Though, this is a pretty
short-sighted fix because eventually we'll have to stop calling
everything 1.0.

I'd be pretty happy removing the version numbers from the configIds,
because I think there has to be a better way to declare and express
version-ness than to bury it in a String that's used for other things.
 I'd rather have a plan say "configId='geronimo/j2ee-server/car'
version='1.0.1' " and a reference say "name='geronimo/j2ee-server/car'
version='1.*' " where the version number is optional for the referrer
(to be used if you really care about locking it down and to be omitted
if you want to maximize portability to other Geronimo versions).  If
we went this way, I guess we would also make the version a separate
property of the ObjectName.

I think supporting wildcards or ranges in the version numbers in
configIds as they are today, and/or treating all version numbers as
wildcards, would be pretty hard to implement.  I also don't think
version ranges or wildcards will work that well.  I expect there won't
be much reason why an application developed and deployed on Geronimo
1.0 wouldn't be able to be redeployed on Geronimo 2.0.  Sure some
things will change, but I hope it will be rare that you might actually
*need* to rewrite an old deployment plan if you just want to redeploy
the same old app and don't care about taking full advantage of
whatever new stuff 2.0 offers.  So if we recommend everyone write 1.x
plans to say "1.*" or "[1.0,2.0)" or whatever, that just means we're
artificially making it impossible to deploy in a future release of
Geronimo without mangling your plans -- and also making configIds a
lot less pleasant to write to begin with
(parentId="geronimo/j2ee-server/[1.0,2.0)/car")

So I think overall I prefer pulling the version out of the configId,
and making it a separate property of the configuration, which you can
use in a reference or not as you please.  Accordingly, I'd also
suggest removing the parentId so any parents have to be declared in a
<import>, where we can make the version number a separate element or
attribute, and I guess we'd need to handle it in GBean references too.

Anyway, bottom line, I'm not real comfortable shipping 1.0.1 without
addressing this in some way.  Maybe we should ship 1.0.1 with all the
configId versions saying 1.0 and then plan to address this ASAP for
1.1 (and maybe even plan to call it 2.0 since it would then be
incompatible with 1.0.x).

Thoughts?

Thanks,
    Aaron

Re: Will 1.0.1 & 1.1 be incompatible with 1.0?

[Paul McMahan <pa...@gmail.com>]

Another option would be to add a new attribute to deployment plans called
something like "isCompatibleWith" or "upgrades".  This attribute would tell
Geronimo that it can use this version of the component in place of the
component that it upgrades.

So for v1.0.1 we could use
<configuration configId="geronimo/j2ee-server/1.0.1/car"
  isCompatibleWith="geronimo/j2ee-server/1.0/car"
  xmlns="...">

and for v1.1 we could use
<configuration configId="geronimo/j2ee-server/1.1/car"

isCompatibleWith="geronimo/j2ee-server/1.0/car,geronimo/j2ee-server/1.0.1/car"
  xmlns="...>

Perhaps using a new element instead of an attribute with CSVs would be
cleaner...

There would need to be some special logic in place to look for cycles and
handle cases where there are multiple components that declare compatibility
with a given component.  Seems like we could arrive at some reasonable
defaults (e.g. choose the node furthest out in the dep chain, last in wins,
etc).

Best wishes,
Paul



On 1/19/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
>
> It seems like if we move ahead as planned for 1.0.1 and 1.1, we're
> going to ship a product with configIds like
> geronimo/j2ee-server/1.0.1/car, which means that many deployment plans
> written for 1.0 will not be able to be deployed unmodified on 1.0 --
> and it will instantly turn a huge number of published articles and
> examples into errors (think of it -- any example including a Geronimo
> configId will be wrong).  Furthermore, there's no way to write a plan
> that will work on more than one specific major/minor/patch release of
> Geronimo, if you have a dependency on a server plan other that the
> default (such as depending on ActiveMQ or CORBA or whatever) or a
> reference to a GBean in a Geronimo configuration other than your own
> (such that the module's configId must appear in the reference, like,
> say, ServerInfo).  I don't know why this hasn't bothered me up until
> now, but I think it's a pretty serious problem.
>
> I think we have a few options:
>
> 1) Ship 1.0.1 with all the configIds saying "1.0" so there is no issue
> for at least that release
>
> 2) Remove version numbers from configIds from 1.0.1 onward, so at
> least we can have backward compatibility from 1.0.1 forward
>
> 3) Put in some logic to treat all version numbers in configIds as
> wildcards
>
> 4) Support explicit wildcards or version ranges in configIds
>
> My opinions on these are:
>
> I think it would be workable to make all the configIds in 1.0.1 say
> 1.0, though it would surely be painful to change substitution
> variables in ALL the plans accordingly.  Though, this is a pretty
> short-sighted fix because eventually we'll have to stop calling
> everything 1.0.
>
> I'd be pretty happy removing the version numbers from the configIds,
> because I think there has to be a better way to declare and express
> version-ness than to bury it in a String that's used for other things.
> I'd rather have a plan say "configId='geronimo/j2ee-server/car'
> version='1.0.1' " and a reference say "name='geronimo/j2ee-server/car'
> version='1.*' " where the version number is optional for the referrer
> (to be used if you really care about locking it down and to be omitted
> if you want to maximize portability to other Geronimo versions).  If
> we went this way, I guess we would also make the version a separate
> property of the ObjectName.
>
> I think supporting wildcards or ranges in the version numbers in
> configIds as they are today, and/or treating all version numbers as
> wildcards, would be pretty hard to implement.  I also don't think
> version ranges or wildcards will work that well.  I expect there won't
> be much reason why an application developed and deployed on Geronimo
> 1.0 wouldn't be able to be redeployed on Geronimo 2.0.  Sure some
> things will change, but I hope it will be rare that you might actually
> *need* to rewrite an old deployment plan if you just want to redeploy
> the same old app and don't care about taking full advantage of
> whatever new stuff 2.0 offers.  So if we recommend everyone write 1.x
> plans to say "1.*" or "[ 1.0,2.0)" or whatever, that just means we're
> artificially making it impossible to deploy in a future release of
> Geronimo without mangling your plans -- and also making configIds a
> lot less pleasant to write to begin with
> (parentId="geronimo/j2ee-server/[1.0,2.0)/car")
>
> So I think overall I prefer pulling the version out of the configId,
> and making it a separate property of the configuration, which you can
> use in a reference or not as you please.  Accordingly, I'd also
> suggest removing the parentId so any parents have to be declared in a
> <import>, where we can make the version number a separate element or
> attribute, and I guess we'd need to handle it in GBean references too.
>
> Anyway, bottom line, I'm not real comfortable shipping 1.0.1 without
> addressing this in some way.  Maybe we should ship 1.0.1 with all the
> configId versions saying 1.0 and then plan to address this ASAP for
> 1.1 (and maybe even plan to call it 2.0 since it would then be
> incompatible with 1.0.x).
>
> Thoughts?
>
> Thanks,
>     Aaron
>

Re: Will 1.0.1 & 1.1 be incompatible with 1.0?

[toby cabot <to...@caboteria.org>]

Aaron,

Thanks for raising this issue - this is important.  It's tacky to
force people to change their plans for a minor version upgrade.

> 1) Ship 1.0.1 with all the configIds saying "1.0" so there is no issue
> for at least that release

I like this option for this branch.  It looks as if the plan names
have changed already but I'd like to see them changed back, (even if
it's a temporary hack for this branch).

> I think it would be workable to make all the configIds in 1.0.1 say
> 1.0, though it would surely be painful to change substitution
> variables in ALL the plans accordingly.  Though, this is a pretty
> short-sighted fix because eventually we'll have to stop calling
> everything 1.0.

I guess since I opened my big trap above, it would be rude of me to
not volunteer to help with the work.  So consider this an offer.

> I'd be pretty happy removing the version numbers from the configIds,
> because I think there has to be a better way to declare and express
> version-ness than to bury it in a String that's used for other things.

Agreed.  If it stays then it should be used for versioning purposes,
i.e. it should be changed to indicate that something has changed
enough to break backward compatibility.  Otherwise it's just make-work
for the users (like me!).

>  I'd rather have a plan say "configId='geronimo/j2ee-server/car'
> version='1.0.1' " and a reference say "name='geronimo/j2ee-server/car'
> version='1.*' " where the version number is optional for the referrer
> (to be used if you really care about locking it down and to be omitted
> if you want to maximize portability to other Geronimo versions).  If
> we went this way, I guess we would also make the version a separate
> property of the ObjectName.

While we're at it, what's the "car" mean?  Is this necessary?

>From a user perspective, the best solution is to not have to use a
parent ID at all, just deploy your j2ee app and it works as expected.
Next best would be to set it once and forget it, next best is to have
to change it every now and then (i.e. big Geronimo version change).
I'm concered about inventing elaborate semantics for the version field
when it's not clear that it helps users.

Thanks again for bringing this up,
Toby