Hi Zoran We have a deprecation policy which seems to have been accidentally skipped with this class. Generally there is at least one major stable release before an old method or class is deleted in favour of another.
My suggestion in this case is that we hold on to this example for a while longer as I can imagine other module writers may hit the same thing. The problem we have is that historically every public method of ArgoUML has been considered the API and available to any plugin to access. What we are hoping to do is publish a smaller stricter API to which we will have a far stronger policy of supporting for a longer period of time. That is yet to come though. Bob. On 15/04/2008, Zoran Jeremic <[EMAIL PROTECTED]> wrote: > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
