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
