Shoud it be a "deprecated" package somewhere?

Engines, Libraries and Tools Xith3D Forums
#1

Hi!

This is just a suggestion…

I think it would be convenient to have the “org.xith3d.deprecated” package in toolkit (or somewhere else), which will contain the classes which where replaced or considerably rewritten, as for example it was done with the TextureLoader.

Suppose we have a class “MyClass.java” somewhere in the core and it was replaced with new version. Rather than renaming class so that two modification can co-exist in same place we just move old implementation to the “deprecated” package.

Next we can agree on kind of “life-cycle” period for those classes in “deprecated”, let’s say - half an year.

As new version of xith is released there is mentioned in the release notes that the folowing classes where substituted and old version migrated to deprecated package as well as it should be mentioned that everybody should start switching to the new implementation because old version will not be available from that and that date (in half a year for instance).

The benefits:
First of all nobody will be in the situation when new release is breaking functionality, as it was for me for example with the TextureLoader - it was not difficult to switch to new implementation, no… but - if for most cases it was working fine, for some - it just didn’t work any good at all :), simply it was needed a bit more time for people to test new TextureLoader (where it were just few little mistakes really but nevertheless…) so it can safely replace old one, which was at least working fine.
If happen so, it is not good enough just to stick to old xith build, because you may need some of its new functionality (for example if I would stick to old build I will have good TextureLoader but I will be missing multipass functionality and vise versa), so one will need to dig the old version out and merge them, so he have old staff which was working fine and new features too.
From another hand having deprecated package will always give possibility to switch to old particullar class (if problems with new one discovered) while meantime new one ongoing bug-fixes, and till the moment old one will be out of its “life-cycle” - the new implementation will be bug-free, well tested and ready to use.

The “life-cycle” can be different…, if it is obvious that there are no bugs - can be very short, for more complicated implementations - could be long…

What you think?

Bohdan.

#2

Could be interesting. But for TextureLoader: This class has been coexisting as TextureLoader2 with Textureloader for a long time afaik.

So I think we should decide from case to case.

#3

Yes, totaly agree. But! Consider new user to xith. Needs a loader… found one… actually 2 of them - cool!!! they have two loaders!! Nice, but which one to use - well, one which is “loader2” - probably something very specific, I’d better use standard one…

And that’s it… :slight_smile: - he will never even try loader2, coz jus “loader” suits him fine… Somebody who was lucky to spot the topic disscussing loaders will know that second one is to replace first one eventualy… but others, who haven’t track on this - they will don’t know.
From another hand having two implementations of same thing in one package - never asumes that any change is upcoming (droping one of them), most of the people will take it just as an alternative… and they will tend to use one they used to already.

Another case. Somebody is busy working on his project and he is regularly checking from CVS or getting new release build, but never look much to forums. At some stage some class he use “SomeClass.java” is planned to be replaced and there is “SomeClassNew / SomeClass2” etc… Well, good, but how the guy should know? The class he use still exist, still with same name, same package - he is even not suspecting that something is going on around class he use and that there is “SomeClass2” there… And the only thing happen to him - would be that some day after xith update - his program stop working… old class removed, new one in its place now… he will spent time to switch - he was not ready… and - he didn’t participate in testing too, by the way… :slight_smile:

But! if I see that class I am using suddenly migrated to package “deprecated” (and I will see that coz I have to fix the import at least, and/or I read release notes) - I would start being worrying, coz it “does what it says ;D”… I will rash to switch. And if a lot of people do - many bugs in new implementation will be discovered fast.
As to TexLoader2 - I just don’t think that many people really where trying much to switch to it…

But if we would have that scary name - “deprecated” and if it would be note in release notes, and probably note in javadoc to that deprecated class - it will kind of force people… yet still giving the chanse to use old implementation if they have a problem with new one, and they will report the bugs meantime.

And, finaly - if somebody didn’t switch, and suddenly he discover that the class removed (life-cycle expired) - well, he have nobody to blame, except himself :wink:

EDIT: BTW, besides moving class to “deprecated”, the class may get a pefix - like “DPR_SomeClass.java” or smth…

#4

I just don’t think many people really read the release notes. They will just recognize the current implementation of their app doesn’t work anymore and won’t realizer there is a deprecated version in some package.

Anyway it shouldn’t happen too often, that a class is simply replaced by a new one. Mostly there will be new methods and the old ones set to deprecated. Or there is a new class like TextureLoader2 (with a better name) and the whole old class set to deprecated. Then people will still be able to compile / run their code and notice some classes or methods are deprecated.

This deprecated thing should be mentioned in the release notes anyway.

I think this is a more practicable way.

#5

Yes, agree with you to big extend…
But still, this is “little” thing, which improves organization, I think… And as people say - every “litre” helps… ;D ;D

#6

Yes, of course. And I think, we will consider doing so, when the next class is “renamed”.

#7

One possibility would be to comment the examples that change from release to release to identify class/behavior mods that were required to make the current version work. This would provide some degree of history for the specific features exercised in the demo code.