Another approach that I implemented on a POS WAN back in the pre-Internet days:
Ship the new stack[s] under a new name. On startup, it checks to see what it's name is...if it isn't MyOldStackName then it reads the data from the old stack[s] into the new stack[s], changes the name of the old stacks, then changes the name of the current stack to MyOldStackName. That way, you're previous rev is still there in case something goes tragically wrong. Ro > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Dan Shafer > Sent: Thursday, July 11, 2002 7:07 PM > To: [EMAIL PROTECTED] > Subject: Updating Data Substacks > > > It just occurred to me that the RR model which requires me to create > a separate stack to hold the data for my app might be an obstacle to > product upgrades. > > My mainstack is a splasher. My substacks are a palette (which can > change) and the primary data stack (which will change). If in my next > rev of the product, I wish to add features (e.g., a menu or even a > button on that stack with some new functions), I would expect to ask > my users to replace their current stack with the new one. But that > will, obviously, result in the loss of all their data. > > How should this work? What am I missing? > -- > -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- > Dan Shafer > Technology Visionary - Technology Assessment - Documentation > "Looking at technology from every angle" > http://www.danshafer.com > 831-392-1127 Voice - 831-401-2531 Fax > _______________________________________________ > use-revolution mailing list > [EMAIL PROTECTED] > http://lists.runrev.com/mailman/listinfo/use-revolution _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
