On Sun, 18 Nov 2001 00:52, Jeff Turner wrote: > There are two documents mentioning versioning: > > 1) The "Optional Package" spec: > The http://java.sun.com/j2se/1.4/docs/guide/extensions/versioning.html
Thats the one I am talking about. > The "Optional Package" spec suggests these manifest entries: > > Extension-Name: javax.help > Specification-Vendor: Sun Microsystems, Inc > Specification-Version: 1.0 > Implementation-Vendor-Id: com.sun > Implementation-Vendor: Sun Microsystems, Inc > Implementation-Version: 1.0 Yep. I just finished implementing this in Avalon/Phoenix, Servlet2.3/Catalina already implements this and newer EJB spec currently (or will) need to support this. I have also been pushing strongly for this to be used in Ant2. There are a few issues with the spec, the two that irritate me mostly are; * there is no formal syntax defined for Extension-Name or Implementation-Vendor-Id. By convention most people use the name of the java packages (ie reverse dns names in most cases) but this is not required. * syntax for versions is dewey decimal and there is no way to indicate backwards incompatability. As long as number is bigger it assumed to be compatible. ie 1.2.3.4.5 is meant to be compatible with 1.3, 2.3, 4.5 and there is no way in lifetime of extension for it to be incompatible. I would prefer a more fixed interpretation (ie major.minor.micro). Ages ago Rodney Waldhoff sent an email titled "RFC: Versioning Guidelines" to commons-dev and I responded to it. I think that had a good interpretation - it was the same as what we have been using in Avalon aswell. > So the questions is, do we want to: > > 1) "add fixed rules of interpretation" to one of these attribute sets +1 > Assuming 1), which spec? We've both been assuming the "Optional Package" > spec, but I think the "Java Product Versioning" spec is more > appropriate, as it is _intended_ to be general-purpose; it's just > horribly under-specified :) I would still use the "Optional Package" even though it has painful terminology and several severe limitations mainly as it is a standard. We can add extra interpretations on top of that to bring it into bounds of reasonable IMHO. Namely fix those two issues above and we would have a workable system. -- Cheers, Pete ------------------------------------------------------- "I would like to take you seriously but to do so would affront your intelligence" -William F. Buckley, JR ------------------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
