Tom, >All the versions >are tagged, so you can check out code for 0.25.4 or even 0.24 if >that's what you really want to do. Otherwise you can just do your >testing against the current SVN code.
It is not necessary for me to be compatible with older versions. If I have understand you well my plugin will work well with 0.25.5 and higher. Its OK for me. But one fact has worried me a litle. You have mentioned that it has changed its name and location several time. Does it mean that somebody could change its location or name in the future versions (i.e. 0.26) and my plugin will not work with that release? Is it good to develop with 0.25.5 developer release if the latest stable release is 0.25.4? Is there any chance that somebody change the code before its become stable release and in that way make my code unusable. Is this source code available through SVN repository something that will keep compatibility with the future releases? Zoran Tom Morris <[EMAIL PROTECTED]> wrote: Oops. Ignore that last message. Introducing a deprecated class using the old name and package will help existing plugin modules to run on 0.26 (provided other incompatible API changes haven't been made), but they won't help Zoran's case unless he develops against the deprecated API (which I wouldn't recommend). Again, developing plugins against a newer version of ArgoUML and running against an older version isn't supported (even if it's only a "little bit" older). All the versions are tagged, so you can check out code for 0.25.4 or even 0.24 if that's what you really want to do. Otherwise you can just do your testing against the current SVN code. The class has been renamed a couple of times up to 0.18.1 TabSpawnable 0.20 - 0.25.4 org.argouml.ui.AbstractArgoJPanel 0.25.5 - org.argouml.api.AbstractArgoJPanel The most recent change was apparently done by Michiel as part of the work for issue 4925 http://argouml.tigris.org/issues/show_bug.cgi?id=4925 but I'm not sure whether it's required for that fix or whether it was an unintentional change that got mixed in. Michiel, can you comment? For backward compatibility should we introduce a deprecated facade class under the old name as Bob suggested or should we move the class back to the original package. Tom [lots and LOTS of lines trimmed here] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] between 0000-00-00 and 9999-99-99
