Q3) not sure if dependency versions should be part of this, for instance upgrading BDB to fix a database issue
Q4) I'm leaning towards regenerating the bootjar even at patch level. It's an integral part of getting TC to function correctly, and having people upgrade with possible error messages that are being reported afterwards about the bootjar doesn't make the process seem intuitive enough to me. However, maybe you can have some patch process descriptor that is interpreted and can cause to bootjar to be forcibly regenerated for only certain upgrades. Q5) we should probably centralize everything in one single source, that can then maybe be used by all the other locations On 04 Jun 2008, at 17:51, Alex Miller wrote: > In looking at updated patch process stuff for the next release, I'm > reviewing all the places we use version information (either to check > compatibility or to report version info). Here's my list: > > Compatibility checking: > > 1) Client/server handshake – Version information comes from > ProductInfo in DistributedObjectClient and DistributedObjectServer and > is actually compared in > ClientHandshakeManager.checkClientServerVersionMatch(). > > 2) Boot jar version check – Version info is written in the boot jar > and then used to check compatibility. This check occurs in > BootJarMetaData constructor. > > 3) Admin console version compatibility check – the check for whether > an admin console is compatible with a server release happens in > AdminClientPanel. > > 4) TIM version compatibility check – TIMs are marked with an expected > TC version and this version is checked in KnopflerfishOSGi class. > > Version reporting: > > 5) Welcome app from kit – shows product version in > com.tc.welcome.HyperlinkFrame.AboutAction. > 6) Eclipse plugin – shows product version (in different forms) in > org.terracotta.dso.actions.[AboutAction, HelpAction]. > 7) Update checker in server – reports to update checker in > UpdateCheckAction. > 8) Server version servlet – reports server version in VersionServlet. > 9) Server Mbean – reports server version in TCServerInfo. > 10) Console logging – version is logged on startup in TCLogging. > > Some questions I had: > > Q1) What is the server version servlet for? > Q2) Am I correct that there is no client MBean that reports version? > (I've looked but didn't see any) > Q3) Did I miss anything you expected to see here? > Q4) In general, I think that all of the compatibility checks should > ignore patch level when checking compatibility. My only question is > whether updating patch level should force boot jar invalidation. > Since this is probably infrequent and would be invasive at a customer > environment in a patch situation, my current thinking is no. > Depending on circumstances, the user might need to force this happen > but we can direct them appropriately in that case. > Q5) Something else I'm thinking about is what we should be reporting > in 5-10 as we report at least 3 or 4 different forms of the version in > those. > _______________________________________________ > tc-dev mailing list > [email protected] > http://lists.terracotta.org/mailman/listinfo/tc-dev -- Geert Bevin Terracotta - http://www.terracotta.org Uwyn "Use what you need" - http://uwyn.com RIFE Java application framework - http://rifers.org Music and words - http://gbevin.com _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
