I agree we could do things to improve our releases. Most ASF releases end up having several RCs, its a natural part of the process, I'm not sure it indicates any failing somewhere. We've been restructuring our builds and distributions recently, with changes like that going on there will be wrinkles.
There's already lots of doc about doing releases in the ASF - on the ASF main dev pages and within the Incubator site etc. If there's omissions from those existing guides we should get them updated. Tuscany having a 'formal release guide' makes me nervous it would just be used as a stick to beat people with when some issue is discovered. An issue with is that currently making our releases is quite a manual process, fixing this would be more worthwhile than writing more documentation (IMHO). So :- - change builds to use the maven release plugin to avoid most of the manual steps when creating a release - use maven to as much as possible automate the adding of dependency information to the LICENSE and NOTICE files - update the RAT tool to validate the legal aspects (LICENSE/NOTICE/DISCLAIMER exist) of things like artifacts in the temp maven repository - update RAT to validate the signatures of all downloadable artifacts All those do require some effort and time though. ...ant On 7/24/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
Should we start thinking on a formal release guide, merging together couple documents we already have as of today, and also creating a checklist as it looks like couple release candidates are having the same issues ? ---------- Forwarded message ---------- From: ant elder <[EMAIL PROTECTED]> Date: Jul 23, 2007 2:48 AM Subject: Re: [VOTE] Release SDO Java 1.0-incubating To: [email protected], [EMAIL PROTECTED] On 7/21/07, kelvin goodson <[EMAIL PROTECTED]> wrote: > > Please vote to release the 1.0-incubating distribution of Tuscany SDO for > Java > > The release candidate RC2 for Tuscany Java SDO archive distribution files > are posted at [1] > The release audit tool (rat) files and associated exceptions are posted at > [1] also > The maven repository artifacts are posted in a staging repository [2] > <http://people.apache.org/%7Ekelvingoodson/sdo_java/M3/RC2/>The tag for > the > source code is at [3] > > > [1] http://people.apache.org/~kelvingoodson/sdo_java/1.0-incubating/RC2/ > [2] http://people.apache.org/~kelvingoodson/repo/org/apache/tuscany/sdo/ > [3] > > http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.0-incubating/ > > Changes in this release are attached below > > Kelvin. > > > What's New in SDO Java 1.0-incubating > > Apache Tuscany's SDO Java Release 1.0-incubating is the first such release > with full coverage of the SDO 2.1 specification. > > In addition to adding the few remaining SDO 2.1 features not included in > the > 1.0-incubating-beta1 release and fixing a number of bugs (see below for > detail) > there are a number of new features relating to XML serialization, and new > support for handling dynamic derivation from static classes. > > For previous revision history, take a look at > > http://svn.apache.org/viewvc/incubator/tuscany/tags/java/sdo/1.0-incubating-beta1/sdo/distribution/RELEASE_NOTES.txt > > SDO Java 1.0-incubating is a superset of previous SDO > 1.0-incubating-beta1release. > Anything in 1.0-incubating-beta1 is also in 1.0-incubating, but > 1.0-incubating contains > features and bugfixes not present in 1.0-incubating-beta1 release. > > Downloading > =========== > > Please visit http://incubator.apache.org/tuscany/sdo-java-releases.html > > Binary Artifact Changes > ======================= > > PLEASE NOTE that > Since the 1.0-incubating-beta release the following binary artifacts have > been renamed > > The maven groupId of the SDO API binary artifact has changed from > "commonj" > to "org.apache.tuscany.sdo" > > The maven artifactId for the SDO API binary artifact has changed from " > sdo-api-r2.1" to "tuscany-sdo-api-r2.1" > > The jar file containing the SDO API has a new "tuscany-" prefix, so what > was .. > sdo-api-r2.1-1.0-incubating-beta1.jar in the beta1 release becomes > tuscany-sdo-api-r2.1-1.0-incubating.jar in this release. > > In addition a new maven artifact and jar has appeared. > > maven groupId=org.apache.tuscany.sdo > maven artifactId=tuscany-sdo-lib > jar archive=tuscany-sdo-lib-1.0-incubating > > This artifact provides a cleear distinction between Tuscany SDO > implementation, and the Tuscany > API which extends the SDO API. See the javadoc contained in the binary > release for details of > the function provded by this artifact. > > > New Features and Fixes > ====================== > > For more detail on these fixes and features please see ... > > https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310210&fixfor=12312521&resolution=1&sorter/field=issuekey&sorter/order=DESC&sorter/field=issuetype&sorter/order=DESC > > New Feature > TUSCANY-1213 SDO 2.1 feature: DataHelper.convert() > TUSCANY-1212 SDO 2.1 feature: Property.isNullable() and > Property.isOpenContent() > TUSCANY-1214 SDO 2.1 feature: XMLHelper.load(Source) and > XMLHelper.save(Result) > TUSCANY-1197 Sequence composition > TUSCANY-1317 Provide a way to set default XML load options to be > used > during Java deserialization > Improvement > TUSCANY-1350 Reorganise SDO build / distribution layout > TUSCANY-1459 Remove package registry delegation to > EPackage.Registry.INSTANCE > TUSCANY-1110 Improve the performance of TypeHelperImpl.getType > (Class) > TUSCANY-1391 Provide capability to load and save XML with unknown > features > TUSCANY-1284 Manifest version number in Java SDO Impl and Tools > jars > TUSCANY-513 Implement support for dynamic subclasses of statically > generated types > TUSCANY-1233 Enhance SDO static codegen (XSD2Java) to support > multiple namespaces in a single pass. > Bug > TUSCANY-1143 Generated code should separate metadata creation from > registration to permit proper scoping > TUSCANY-1428 XSD2JavaGenerator.GeneratePackage information is > invalid > TUSCANY-1429 Using default helper context got ClassCastException > due > to T-1317 > TUSCANY-1446 Java SDO samples don't compile with JDK 1.4.2 > TUSCANY-1457 Unable to code gen SDOModel.xsd > TUSCANY-1430 SDO codegen is needs to use internal property numbers > for inverseAdd, inverseRemove, and notify calls > TUSCANY-1207 TCCL-specific EcoreBuilders must be used by default > XSDHelper > TUSCANY-1127 ObtainingDataGraphFromXml, and maybe other samples, > incorrectly accessing xsd:any content > TUSCANY-1254 Codegen on a type inheriting from a type in different > namespace will result in mis-mapping the feature IDs > TUSCANY-993 Problems with sdoModelExtended.xsd > TUSCANY-1223 XSD base64Binary type mapping to wrong SDO type > TUSCANY-1251 Code generated from xsd:base64Binary types fail to > compile > TUSCANY-1333 [Java SDO] ClassCastException when defining schema > file > without .xsd extension > TUSCANY-1410 DataHelperImpl.toCalendar() with null locale should > use > default locale > TUSCANY-1324 DeserializationNoSchemaTestCase took a long time to > run > TUSCANY-1369 EMF 2.2.2 Dependencies from ISU are Stale > TUSCANY-1352 NPE in > SDOXSDEcoreBuilder.XSDSchemaAdapterFactoryImpl.SchemaLocator.locateSchema > TUSCANY-1325 Property value with xsd:QName type is not deserialized > and serialized correctly > TUSCANY-1250 Static SDO generator generates an erroneous factory > class, when inheritance and different Java packages are used > TUSCANY-578 Exceptions thrown by SDO runtime not the same as > defined > in the spec > TUSCANY-1421 XMLHelper.save on root object of DataGraph gives > serialization of href="root.xml#/" > TUSCANY-1436 TypeHelper.getType(java.util.List.class) throws > ClassCastException > TUSCANY-1385 Duplicate namespace was serialized when SDO QName > property value containing existing namespace > TUSCANY-1122 TypeConversionTestCase fails for JDK 1.4.2 > TUSCANY-1408 Cannot programmatically define a SDO property matching > to XSD element > TUSCANY-1393 ClassCastException saving codegen-based DataGraph with > ChangeSummary containing an xsd:int > TUSCANY-1305 Changesummary of datagraph using static interfaces. The only big issue I can see is that the sdo api jar in the maven repository doesn't include the LICENSE/NOTICE/DISCLAIMER files. Could fix that just by adding the files into the jar but it would be better fix the build and respin the release. Some other comments: The other jar's in maven repo still have disclaimer info within notice and and they don't really need the non-AL stuff in the license, also all the artifacts in the repo need to be signed. The samples artifacts shouldn't be included in the maven repo should they? Or if the intention really is to publish them then they need the legal files and the artifact names to include Tuscany. The build is using a snapshot of maven-osgi-plugin, be great if that could be a real release. There's optional dependency listed for asm, but i couldn't find anything saying what requires that or what its for but wondered if it should be distributed anyway even though its use is optional? I still think a sentence or two at the start of the release notes saying "what is SDO" would be good, copying from one of the articles mentioned in the samples how about - "Service Data Object is an open standard data model programming API that allows the developer to easily manipulate data at a high level." - though I'm still not really sure what that means, is SDO just a kind of new XML data binding technology on steroids? ...ant -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
