[jdom-interest] (no subject)

[Jason Hunter]

> As Vadim said, we are part of the early JDOM adopters. We trust JDOM and try to promote it to our customers. Most of
> them already developped code that uses JDOM, based upon our framework. So, when a new incompatible JDOM is to be
> released, what should we do? Stay with the old version or move to the new one?

I figure we'll keep getChild() and getChildren() deprecated for a long 
time, so things will keep working even with the new one.  As much as 
possible we've tried to deprecate public methods so you have a beta 
cycle in which to migrate.  Some rare times it's not possible, but it's 
been our goal.

> I noticed that each time a new Beta is to be released, we have to do significant changes to our code. 

Well, you had to make changes to avoid deprecation warnings.  But it 
probably worked.  And it's because we're still changing the API that we 
haven't called it 1.0.

> This is not the definition of a beta release, where things should be improved and corrected, but not changed. 

I've never seen a beta, esp an open source beta, that had a completely 
frozen API.

> Especially when the beta
> step is 10!! Else, call it JDOM 0.9x, but not 1.0.

We never called it 1.0.

> Jason, here's what you wrote last january:
> 
>>It's widely used, and we really should have called it 1.0 before now.
>>There's several people who volunteered to help push to 1.0, so we'll do
>>that as soon as we get CVS.
> 
> So, how can you let people doing such changes to CVS, and not waiting for 1.1, 2.0 or later?

You'd rather we ship 1.0 and then break things in 1.1?  That's no good. 
  We're going to get the API right for 1.0 so we don't have to break 
anything later.

> Finally, I suggest to add a static field to JDOM that gives the current API version. 

The JAR contains this in the manifest and it can be inspected.

-jh-