Simon Nash wrote: > > I think the same reasoning should apply to the org.osoa jars. > We should not tie them to a particular SCA spec revision, such > as 0.92, while the spec is stil evolving. For example, by the > time we release M2, the spec may be at 0.93 or later. Also, not > all parts of the spec are currently at 0.92. Some are at 0.95. > For SDO APIs, the spec level that we are supporting is a mix of > 2.01 and 2.1. I'm inclined to think we should just use > 1.0-incubating-SNAPSHOT > for the spec jars as well. >
I think perhaps I wasn't quite clear enough. The "0.92" bit was really just an example. What I was really trying to say was that the version number for the spec jars should contain somewhere the version number of the spec document that the jar related to. It would be completely independent of the version of our implementation. Following this convention, the version for the jars we released with M1 would change to 0.9-incubating as the Java C&I spec from November is "SCA Version 0.9, November 2005" When the next draft is published, the version would then be bumped to 0.92-incubating or whatever the final version of that draft is. We don't need to wait until M2 to version these jars - IMO their release cycle should be tied to specification releases rather than our implementation releases. This would also mean that the SDO API jars had a different version number, probably 2.01. Again this is different from what we support in a particular implementation release. The API jars should be a resource that can be used independently from Tuscany. For example, someone should be able to compile against them and know that their application would be portable to any other SCA implementation (at least at the API level, whether it worked would be a different issue). -- Jeremy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
