ArgoEclipse manages its versions using the Eclipse versioning mechanism, so it has no need for a separate versioning framework. It is useful for it to have access to the core ArgoUML version to present to the user because this is the user friendly name for a set of features, bugs, API & file format versions. For example, the ArgoUML version is key to understanding what bugs got fixed when or when a new feature was added.
Plugin modules probably want two different types of version information: 1) an API version number to check for compatibility and 2) a user presentable version string to put in displays, generated files, etc. Since we've removed the small tightly controlled public plugin API and now the API is basically anything in ArgoUML, I suspect we're going to have many more compatibility issues moving forward. I'd really like to see us be much more restrictive about what the public API is (and/or get *much* more disciplined about API stability). Tom > -----Original Message----- > From: Linus Tolke [mailto:[EMAIL PROTECTED] > Sent: Sunday, April 29, 2007 2:03 AM > To: [email protected] > Subject: RE: [argouml-dev] Detangling ArgoUML's dependency web... > > > Hello Michiel! > > You don't have to move the ArgoVersion class. You can let the > Application subsystem register the version with some low > level subsystem when it starts and then all other parts > retrieve the version from there. > > The question we should ask ourselves is what the version of > the application represents. If it represents the version of > the application, then it would be good to register it like > this. As a consequence ArgoEclipse would have its own version > registered by its own application subsystem (since it is > another application). If it represents the version of the > code then it should be down there everywhere. In the second > case I think it is rather pointless because we have > subversion and our configuration management work to keep > track of what version of every file that goes into every distribution. > > It looks like it is used for information (the splash), in > projects and then when saving the model. I suspect that when > it is used in the project and for saving the model it is more > or less just information since we also have a persistence version. > > I would like to suggest that we register it somewhere where > the splash, the code generation and model saving can fetch > the information, let test cases register something > appropriate for their test, and let ArgoEclipse register its > own version. > > /Linus > > > > -----Original Message----- > > From: Michiel van der Wulp [mailto:[EMAIL PROTECTED] > > Sent: den 21 april 2007 19:02 > > To: [email protected] > > Subject: [argouml-dev] Detangling ArgoUML's dependency web... > > > > Hi All, > > > > One other thought about my effort to work on dependencies: > The easiest > > thing to do, is find the packages at the complete "top" > and at > > the "bottom", so that is what I started with. > > > > The latter I talked about in my previous mail, but the top > > package/subsystem is org.argouml.application, i.e. the Application > > subsystem, according > the > > cookbook. > > > > That would mean, that the ArgoVersion class does not belong in this > > package...since it is used in many places all over ArgoUML, and even > by a > > few plugins. > > Can we move this class? (And where to?) > > > > Regards, > > Michiel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
