I'd like some more information before answering this poll. Namely, what exactly is serialized? I guess I was under the impression
that "configuration information" was serialized. You make it sound like,
for example, ActiveMQ itself is serialized. Shouldn't we be able to
serialize a bunch of settings (port=61616, active transport 1 =
vm://localhost, active transport 2 = tcp://localhost:61616, ...) and apply
those to version N+1 of ActiveMQ, so long as it didn't remove settings we
use or add new required ones without defaults that we don't use? Are we just not doing that? I guess I need to take a closer look.
Also, wearing my end user hat, I'm not as concerned about this
issue as stated -- Every time I upgrade, for example, JBoss, I install it
into a new directory, reapply any configuration changes, and redeploy my
apps. It might be different if the product offered an "upgrade in place"
install option. Still, I upgrade pretty rarely. So an easy upgrade path is probably for me, at best, a "nice to have".
I posted those comments I promised and hope they clarify why this is a big deal to me - basically, that massive deployment madates automated "upgrade in place"
In reality, with the model you describe applications will always get redeployed (and hence the config bundles rebuilt) in the new configuration and none of the versioning issues apply.
I'm more concerned about the inability to conveniently edit serialized configuration information, which I hope to take up on the other thread that Jeremy was going to start. That is a lot more of a common issue for me -- more of a "must have".
Let's run through the use cases there as I think there are many options for this.
-- Jeremy
