On Jun 6, 2008, at 10:13 AM, Geert Bevin wrote: > Q3) not sure if dependency versions should be part of this, for > instance upgrading BDB to fix a database issue
It is definitely included (we talked about this exact scenario actually). This is why the process includes being able to update any file in the kit. > 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. I thought about this issue for a while. I think any process that *requires* boot jar to be recreated is unacceptable. We may be patching in production in scenarios where it's simply not feasible to easily rebuild the boot jar (and in vast majority of cases, we shouldn't need to anyways). But I hadn't considered fully making this forced per-patch. Definitely food for thought. > > > Q5) we should probably centralize everything in one single source, > that can then maybe be used by all the other locations The info is already centralized in ProductInfo, but all the various locations create their own custom strings based on different parts of it. I'll review all of it when we implement and see if I can suggest some uniformity. Thanks for reading! > > > 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 _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
