xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Pogue <mpo...@apache.org>
Subject Re: Proposed guidelines for package distribution of Java projects
Date Mon, 22 Nov 1999 17:38:11 GMT
The isCompatible function can be very difficult to maintain, and it's an
additional source of bugs. What if two version are compatible, but
isCompatible says they are not? 

The real problem with a single isCompatible() function is that there are
multiple levels of "compatibility" (listed here roughly in best-to-worst
order).

	binary compatibility - you can drop in the new version, and everything
works.
	link compatibility - you can use the new version, but it requires a
relink
			(but not a recompile).
	source compatibility - you can use your old source code without change,
but a
				recompile is required.
	package compatibility - you can use your old source code, but you have
			to change the package or header name for some things you include.
	call compatible, semantic incompatible - you have to change your source
code,
			because although the function signatures are the same as before,
			the semantics have changed (this happens a lot with functions
			that return strings, where the format of the string changes).
			Frequently, the semantics of the string aren't even in the docs!
	incompatible - all bets are off.  Incompatible API signature change,
for example.

In my experience, there's always somebody who wants to know the answer
to each of these.
Even with three version numbers, it's not enough for some people, IMHO. 
A single isCompatible function is too little information, in my
experience.

Mike

Stefano Mazzocchi wrote:
> 
> David_Marston/CAM/Lotus@lotus.com wrote:
> >
> > I have extensive experience with the versioning issues raised by Stefano. I
> > support the idea
> > of a Version class.
> >
> > At this point, I only want to suggest that we be more explicit about the uses of
> > the version labels.
> >
> > >1) Versioning
> > >
> > >I propose that every package named
> > > org.apache.xxx
> > >contains a class named Version like this
> > >
> > >public class Version {
> > >...
> > >   public static String getVersion() {
> > >    return "1.6"
> > >   }...
> > >}
> >
> > We should be explicit about whether we intend this version label to
> > be usable in strict numeric comparisons, meaning that there is just
> > one decimal point. If more than two "decimal" fields are allowed, then
> > you can still test whether the version is earlier than a minimum, but
> > it's not as easy as a simple numeric < test. However, multiple fields
> > are nice for isolating different degrees of change in the different
> > release levels.
> 
> Instead of hardcoding the versioning type, in the Avalon project we came
> up with something like
> 
>   boolean isCompatible(Version version);
> 
> which returns false if the given version is compatible with the called
> one, compatible means that it can be replaced with no behavioral
> difference. It's up to the Version implementor to come up with the logic
> to evaluate this (a simple yet valid implementation would always return
> false, while normal implementations will return true if in an x.y.z
> version x and y are equal)
> 
> > 3) package name
> >
> > >I propose the following name model for packages
> > > name[-type]-version.jar...
> > >note that "name" and "version" _must_ be the one passed by "getName()"
> > >and "getVersion()" methods in Version.
> >
> > This raises some interesting possibilities in the build/make area.
> > Can we put the name and version labels in exactly one place in the
> > source, then generate the package name from them?
> 
> What about
> 
> public class Version {
> 
>   ...
> 
>   public static void main(String args[]) {
>      system.out.println(getName() + "-" + getVersion());
>   }
> }
> 
> so you can call
> 
>    java org.apache.<project>.Version
> 
> and you have
> 
>    Name-Version
> 
> than you can add "type" if required and get
> 
>    Name-Version[-type].jar
> 
> (which changes the original proposal a little) how's that?
> 
> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <stefano@apache.org>                             Friedrich Nietzsche

Mime
View raw message