Hi!

I've just committed new ebuilds for dev-java/istack-commons-runtime-1.0
and dev-java/istack-commons-tools-1.1 to java-experimental, based on the
java-mvn-src eclass I committed along with it. Now I wonder how to deal
with version numbers, as previous versions were based on CVS snapshots
and had a date as their version number, i.e. 20070122 and similar.

I can think of two possible solutions:


1. Rename all 2007* ebuilds to 0.2007* in order to have 1.0 a higher
version than these.

Would require modification of all ebuilds that depend on a specific
version of an istack-commons package. I found no such dependency in the
main portage tree right now. In java-experimental there are two, for
dev-java/jaxb{,-tools}-2.1.5.

The ebuilds in the main portage tree would need to be renamed as well,
which would probably cause recompilation due to downgrading for quite a
few users out there. As the packages are rather small and build quickly,
I see little point in trying to avoid these recompiles. Users in ~ARCH
would probably directly upgrade to the 1.* releases in any case.


2. package.mask the 2007* ebuilds.

For this to work, the 1.* ebuilds would need to be stabilized fairly
quickly, so that users can update to an unmasked version. The package
itself is simple enough, but I guess the introduction of a new eclass
would warrant some extended testing, especially using different java
compilers, before stabilizing it.

Ebuilds actually requiring an 1.* version of an istack-commons package
would have to depend on ">=*-1.0 <*-20000000" or similar in order to
express their actual dependency. For ebuilds like the jaxbe ones
currently in java-experimental that would have to be even more
complicated: "|| ( >= *-20070711 ( >= *-0.20070711 <*-20000000 ) )".


I believe that the first solution would be the best one. I hope some
developer with access to the main portage tree will implement this,
either now or when istack-commons-* is about to hit the main portage tree.

The second approach is useful for testing, and expressing dependencies
in this way would help migration, as dependency information wouldn't
have to be changed at the same time as ebuild names.

Greetings,
 Martin von Gagern