Spoon May 2008

spoon@lists.squeakfoundation.org

2 participants
2 discussions

Use Cases
by Ken G. Brown 14 May '08

14 May '08

In my dev8.04.1 working image I had manually applied some fixes from a separate Workspace to make toggle-break-on-entry work again from the method pane contextual menu. I forget at the moment which ones they were. As well i applied most of the stuff from installer.pbwiki.com. Plus a lot of other stuff. When upgrading to dev8.05.1 I would like to be able to easily compare what is different from dev8.04.1 in order to know which fixes have already been included in the new release, and therefore I do not have to manually include anymore. This also applies to the scripts on installer.pbwiki.com. Which of the fixes in the scripts have already been applied in the new dev release and I will no longer need to do. Maybe this would be as simple as applying my complete list of fixes in the new release, but having the ones already there be flagged so I can remove them from the new installer script for fixes. A full status report of some sort would be handy to evaluate the 3-way diff between what's there in new, what's there in previous, and what you intend to install now. Thx, Ken G. Brown

1 0

Re: request for use cases
by Ken G. Brown 13 May '08

13 May '08

I suspect these are well covered already however, here are some use cases I can see, not in pseudo-code form yet, just a brain dump: - Of course start from absolute minimal image, scriptable loading of everything you want. - Tools to automate remembering of things you add during day to day work, so that you can reload everything again by script eg. when migrating your working image contents to a new base version.. - When attempting to load a new package, I would like to be notified if the package already exists in the image and whether or not any parts of it have changes in the new. I don't want to just blindly reload a package on top of what was already there. - When I attempt to load a new package, and something happens during the install, eg. a DNU appears, I would like to be able to be able to completely undo the install and be guaranteed that everything is restored to an identical state to before I started installing that particular package. - When installing a new package that contains new versions of Classes or methods which are already existing in the image, I would like all previously installed software to continue to work with the previously existing Classes and methods as was the case before the install of the new package was attempted, unless explicitly desired to update previous senders to the new versions. There should be tools to allow study of the existence of multiple versions of the same named Classes and methods currently 'live' and selectively be able to move some or all incidences of using old versions to new. eg. if Flow could have been loaded even though it changed some core functionality, while maintaining use of all older versions at the same time, it would have been much easier to test out Flow for new development while having confidence everything existing would still work as before. Eventually when desired, migration to all new could be done with appropriate tools. This would overcome the majority of fear people have of moving forward and breaking backward compatibility. - Any previously installed version of a package should be completely unloadable to a previous state as though it was never loaded in the first place. If some other package had subsequently utilized some of the loaded package items since it was installed, this should be flagged at the time of attempted unload and the conflicting items could be moved to the package still requiring them. Other options may be needed here too such as creating another new package to hold the still required items that could not be unloaded. Loading and unloading should be guaranteeably undoable so that you can always have confidence there are no side effects. - A facility for tracking certain ongoing modifications to the image would be beneficial, to be done in such a way that the current state of your working image could be reconstructed from a known starting point such as a new release version. Think taking a release 3.10, running a script to load all the additions to make it a dev image, then continuing on reloading all the stuff you had been working on since the last time you started from a fresh release image. This is currently possible with Installer scripts but it is a manual process to keep adding pertinent work to saved copies of Workspaces, your local Monticello Repository and your custom installer script. - loading and unloading packages should work the same whether on not you have Internet connectivity as along as you have local copies of required items available. Tools might be required to verify that your image can be restored from local copies to facilitate working in offline mode. Synch tools may be required here. eg. you start working on a new package on your mobile computer while lounging at your mountain cabin or when at the campground in your RV. You have no Internet available there. You get home and you update/sync your more powerful desktop computer so you can do more work there more conveniently with your large screen real estate. You only have dial-up there so you continue working mostly offline but on the desktop system rather than the laptop. You need convenient way to keep the laptop and desktop systems in sync. At some point you find a high speed connection (eg at Starbucks) so you post your current work from the laptop to an online server somewhere. Later you finally return to the office where you only have a desktop computer and you sync that as well so you can continue your development. This should all be easy and convenient to keep all sync'ed whether or not you have Internet connectivity. Of course the required synch paths will need to be there when needed. eg. laptop to online repository. - A variation of this theme would be taking everything with you on a usb storage device to another computer altogether. Thx, Ken G. Brown >Message: 1 >Date: Thu, 03 Apr 2008 13:42:35 -0700 >From: Craig Latta <craig(a)netjam.org> >Subject: request for use cases >To: spoon(a)lists.squeakfoundation.org >Message-ID: <47F5413B.7060100(a)netjam.org> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > >Hi-- > > Naiad, Spoon's module system, is starting to work. I'm working on >a solstice release (2008-06-20). I'd like to collect desired use cases >from interested folks. Please let me know of any that come to mind. >Unwanted scenarios you've encountered with other change management >systems would be useful, too. Please use the Spoon list for now, I'm >sure we can come up with some wiki-ish place for them soon. > > I'll start with one: > > - Create a class. > - Create a method for that class. > - Create another method for that class. > - Create a second version of the first method. > - Remove the first method. > - Add an instance variable to the class. > - Create a third version of the first method. > - Remove the class. > - Reinstall the original version of the class. The class appears >with its original original instance variables and the methods it had >just before the new instance variable was added. > > It seems to be me that English descriptions of use cases could >serve as pseudo-code versions of tests, developed into actual code later >on. Also, most of these tests will probably be composed of several >simpler tests (as above). > > > thanks! > >-C > >-- >Craig Latta >improvisational musical informaticist >www.netjam.org >Smalltalkers do: [:it | All with: Class, (And love: it)] <>

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Spoon May 2008