There are various reasons why it is not possible to load a zargo file from a current release in a previous version of ArgoUML.
I think there are 2 major problems that cause regular change. 1. Fixing errors in save due to previous ArgoUML bugs Some of these fixes must not be repeated. By saving a persistance version we ensure that a fix is run once and only once when we know that it is required. 2. Use of PGML and reflection to save and load diagrams The current method of saving diagrams as PGML means every time we adjust the composite make up of a Fig then persistence format differs. The problem comes if we have introduced some new Fig or refactored the name or package of an existing Fig. For the current ArgoUML to read previous projects we have no problem as the upgrade XSL adjusts the project for these changes. However when a previous version of ArgoUML is used to load such a project it will attempt to create each Fig by reflection using the class names stored in the PGML. Obviously it won't find these and BANG. In the past this tended to mean some random exception being presented to the user, the user creates issues in the database which we have to investigate and our reply was always upgrade to latest version. This is why I introduced the persistence version. A value that increments each time such a change has taken place. Instead of an exception the user now sees a message asking them to upgrade. I hadn't previously seen this as a problem because ArgoUML is becoming more stable and we want to push users towards that more stable release. I've tried to make changes as gradual as possible saving any more major changes until after a stable release of ArgoUML. Changes to the Fig structure are certainly likely. Issue 3238 and issue 4426 spring to mind immeditely. We have problems now though of requirements of http://argoeclipse.tigris.org The argoeclipse project is not planning to keep step with ArgoUML releases. They are keeping to their own schedule. This means that the latest version of argoeclipse may not be able to read a save file from the latest version of ArgoUML. The only solution I see is to move to a more formal fixed format than PGML for which we need to make a reader and writer that will be modified for each version. The logical choice with be the OMG diagram interchange format but I was hoping not to do such major change for a long time. With all of the above commments I'm not so sure if it's worth spending time on issue 4431. This will not solve the requirements of argoeclipse as they will have compatability problems anyway. But it seems we have a catch 22. The requirements is to stabalise the persistence format but in order to do that we need to change the persistence format. How do we go about this? As a slight aside. There has been some talk a couple of months back about moving to ArgoUML 1.0. To my mind the most important thing for that release is not the bug count but a stable and formal API and persistence format. I think we have some way to go for that. Is that what we should be concentrating on now? Bob. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
