[jdom-interest] Why are version numbers so complicated?

[Rolf Lear]

There is a practical issue in that (apart from the increased Jar size). 
I build the maven bundle using an ant task, and the ant task only has 
the current version of the source available. I would need to access the 
JDOM 1.x jar, unjar it, and then rejar it in to the jdom 2.0.0 bundle.

Not that it is impossible, but, at any one point in time, I only have 
one branch of the git repository open.

Also, remember, a requirement of the oss-nexus (the way I have linked in 
to maven central) is that I have to have the Javadoc and source 
available for all Jars. This would make the process too unwieldy for the 
perceived benefit.

I think that some maven users will be suprised by a new jdom 2.0.0 
release which causes compile failures, but, this will be a distinct 
minority, and easily resolved.

Additionally, I think I need to say that I really want JDOM 1.x usage to 
'die'. I personally have very little interest in maintaining JDOM 1.x. 
It is not 'sexy' work. I am also pragmatic in the sense that I know it 
takes time to migrate (for example, I know it will take years to 
accomplish that even where I work), but when JDOM 2.0.0 is available, I 
think people need to know in as many ways as possible....

So, I don't think there is any way that I will bundle JDOM 1.x with JDOM 
2.0.0. It sends all sorts of 'wrong' messages.

I think there is enough incentive as it is to move... but I am biased. I 
don't see how bundling jdom 1.x with jdom 2.x is going to add incentive 
though... it will just add to the inertia to 'stay'.

Rolf

On 17/03/2012 1:49 PM, Paul Libbrecht wrote:
> Why not make a package org.jdom with artifactId jdom version 2.0.0
> containing both packages (org.jdom and org.jdom2) with every class in
> org.jdom deprecated?
>
> It's a bit more work but it might offer a good incentive for the move.
>
> paul
>