<humor>
Oh, for Pete's sake, this poll is about as Fair and Balanced as Fox News.

How about:

PROJECT POLL:
  [ ] We, ${projectName}, didn't really mean it when we said something
      was Serializable and feel free to change our APIs and
      implementation at any time without telling you.

  [ ] We do our best to ensure our public APIs, but use of them is not
      supported by us. Good luck guys.

USER POLL:
  [ ] I am a ${otherProject} user and quite like the incompatibilities
      between even minor dot releases - it gives my admins something to
      do. Please make sure ${projectName} behaves this way as well

  [ ] I believe the safest way to upgrade something is to wipe out
      everything that is there and start over every time. That way
      I don't get cooties from old software.

</humor>

OK, so it probably isn't that funny but let's at least have a serious discussion about this.

--
Jeremy

David Blevins wrote:
I really want to get some feedback from the developers, users, lurkers, other projects and everyone 
on this subject.  It shouldn't be a taboo to talk about or considered a "can of worms" or 
a "hot button."  It affects the project at pretty fundamental level, so I think it would 
be good if we did our best to get feedback.

The problem:

  Upgrading apps between versions of Geronimo and it's integrated projects is 
not currently possible without a redeploy.

The facts:
  - Our deploy system and storage of deployed apps is serialization based.
  - At deploy time we build and Jetty web containers, Tomcat web containers, 
ActiveMQ queues/topics, OpenEJB ejb containers, Axis webservices, TranQL 
connectors and more
  - We serialize those objects which include not just what they consider to be 
their public APIs but also the private implementations of those APIs.

The tricky part:
  - We, qualified in alphabetical order, ActiveMQ, Axis, Geronimo, Jetty, 
OpenEJB, Tomcat, TranQL, et. al. cannot change our public API *or* private 
Implementation of our APIs and still deserialize objects from a previous 
version.
  - Unless we (the projecst above) agree not to bug fix, optimize, refactor, 
repackage, or reorganize our code in a way that would break deserialization of 
objects created with a previous versions of our code, it will not be possible 
to upgrade applications leveraging these projects without a redeploy.


PROJECT POLL: [ ] We will do our best to ensure the implementations of our APIs are serialization compatible to future versions of our code. [ ] We do our best to ensure our public APIs, but use of our implementations in such a way is not supported by us.

USER POLL:
  [ ]  I do not mind redeploying my applications on each upgrade of Geronimo 
et. al.
  [ ]  I do not want to start from scratch on each upgrade of Geronimo et. al.



-David






Reply via email to