You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Luciano Resende <lu...@gmail.com> on 2007/07/24 01:39:03 UTC
Release process & guide & checklist, was Fwd: [VOTE] Release SDO Java 1.0-incubating
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 <an...@apache.org>
Date: Jul 23, 2007 2:48 AM
Subject: Re: [VOTE] Release SDO Java 1.0-incubating
To: tuscany-dev@ws.apache.org, kelvin@thegoodsons.org.uk
On 7/21/07, kelvin goodson <ke...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Release process & guide & checklist, was Fwd: [VOTE] Release
SDO Java 1.0-incubating
Posted by Mike Edwards <mi...@gmail.com>.
Luciano Resende 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 ?
+1 - yes, most definitely.
Yours, Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Release process & guide & checklist, was Fwd: [VOTE] Release SDO Java 1.0-incubating
Posted by Luciano Resende <lu...@gmail.com>.
Let me come up with some initial document over the weekend, and we
could start providing feedback on top of that, also we could check if
there is going to be any value on that or not.
On 7/25/07, ant elder <an...@apache.org> wrote:
> As an example of how much simpler things could be if we got our maven builds
> set up so maven automated everything see:
> http://incubator.apache.org/cxf/building.html#Building-Performingarelease
>
> But, I still think a RM should understand whats going on so mvn shouldn't be
> a substitute for having read all the ASF and Incubator doc about releases.
>
> ...ant
>
> On 7/25/07, Venkata Krishnan <fo...@gmail.com> wrote:
> >
> > Hi,
> >
> > I'd like the release guide if the steps we follow are a bit different
> > than what is normally done or if there are some variations to how we
> > perform some steps. But if we were just about going to rephrase all
> > of what has already been said somewhere else I'd prefer just about
> > having a pointer from Tuscany. Maybe a good begining to all of this
> > could be to have our release guide and link to the information that is
> > available. Then as we get to review and apply that we could flesh our
> > guide.
> >
> > Having said that, I'd like us to have a 'release review checklist'
> > that enlists the bunch of things that need to be reviewed in a RC
> > including things like testing out the binary distro before the source
> > distro. etc.
> >
> > - Venkat
> >
> > On 7/24/07, Simon Laws <si...@googlemail.com> wrote:
> > > snip..
> > >
> > > >
> > > > There's already lots of doc about doing releases in the ASF - on the
> > ASF
> > > > main dev pages and within the Incubator site etc.
> > >
> > >
> > > The problem with there being lots of docs is that there are, ahem, lots
> > of
> > > docs. Where is the definitive set of guides that provide the detail
> > required
> > > to release Tuscany for someone, like me, who hasn't done it before?
> > Possibly
> > > an impossible question to answer as you don't know what I don't know and
> > I
> > > don't know what you do know so our view of what is an acceptable level
> > of
> > > detail probably differs. Here are the top level guides I found.
> > >
> > > http://www.apache.org/dev/#rreleases
> > > http://incubator.apache.org/guides/releasemanagement.html
> > >
> > > I can't say whether the above links are satisfactory as I haven't been
> > > through the process but I agree that we should propose updates if they
> > are
> > > found to be wanting. For example, a discussion of RAT.
> > >
> > > For consistency I would expect to see all the keystrokes recorded that
> > are
> > > required to produce and distribute a release. The fewer the better so,
> > yes,
> > > more automation would be good. I expect automation does not completely
> > > remove the responsibility to check the release against release criteria,
> > > e,g, legal, but gives a good indication of what is required to make the
> > > release happen. Again anything we can do to automate these checks is
> > good.
> > >
> > > I don't expect that release is a process that should involve a lot of
> > > imagination on our part other than in providing more automation of the
> > > required steps. To put it another way is there anything specific we have
> > to
> > > do for Tuscany that would not be included in the general guide? I note
> > that
> > > many projects do have release guides. Why is this the case?
> > >
> > > http://httpd.apache.org/dev/release.html
> > > http://cayenne.apache.org/release-guide.html
> > > http://incubator.apache.org/servicemix/release-guide.html
> > > http://activemq.apache.org/release-guide.html
> > >
> > > I do note that the Incubator release guide states "Different options or
> > > opinions are encouraged.". If options are offered (and I can't say that
> > > there are without reading the detail) then we need a place to document
> > which
> > > are chosen for Tuscany releases.
> > >
> > > Simon
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Release process & guide & checklist, was Fwd: [VOTE] Release SDO Java 1.0-incubating
Posted by ant elder <an...@apache.org>.
As an example of how much simpler things could be if we got our maven builds
set up so maven automated everything see:
http://incubator.apache.org/cxf/building.html#Building-Performingarelease
But, I still think a RM should understand whats going on so mvn shouldn't be
a substitute for having read all the ASF and Incubator doc about releases.
...ant
On 7/25/07, Venkata Krishnan <fo...@gmail.com> wrote:
>
> Hi,
>
> I'd like the release guide if the steps we follow are a bit different
> than what is normally done or if there are some variations to how we
> perform some steps. But if we were just about going to rephrase all
> of what has already been said somewhere else I'd prefer just about
> having a pointer from Tuscany. Maybe a good begining to all of this
> could be to have our release guide and link to the information that is
> available. Then as we get to review and apply that we could flesh our
> guide.
>
> Having said that, I'd like us to have a 'release review checklist'
> that enlists the bunch of things that need to be reviewed in a RC
> including things like testing out the binary distro before the source
> distro. etc.
>
> - Venkat
>
> On 7/24/07, Simon Laws <si...@googlemail.com> wrote:
> > snip..
> >
> > >
> > > There's already lots of doc about doing releases in the ASF - on the
> ASF
> > > main dev pages and within the Incubator site etc.
> >
> >
> > The problem with there being lots of docs is that there are, ahem, lots
> of
> > docs. Where is the definitive set of guides that provide the detail
> required
> > to release Tuscany for someone, like me, who hasn't done it before?
> Possibly
> > an impossible question to answer as you don't know what I don't know and
> I
> > don't know what you do know so our view of what is an acceptable level
> of
> > detail probably differs. Here are the top level guides I found.
> >
> > http://www.apache.org/dev/#rreleases
> > http://incubator.apache.org/guides/releasemanagement.html
> >
> > I can't say whether the above links are satisfactory as I haven't been
> > through the process but I agree that we should propose updates if they
> are
> > found to be wanting. For example, a discussion of RAT.
> >
> > For consistency I would expect to see all the keystrokes recorded that
> are
> > required to produce and distribute a release. The fewer the better so,
> yes,
> > more automation would be good. I expect automation does not completely
> > remove the responsibility to check the release against release criteria,
> > e,g, legal, but gives a good indication of what is required to make the
> > release happen. Again anything we can do to automate these checks is
> good.
> >
> > I don't expect that release is a process that should involve a lot of
> > imagination on our part other than in providing more automation of the
> > required steps. To put it another way is there anything specific we have
> to
> > do for Tuscany that would not be included in the general guide? I note
> that
> > many projects do have release guides. Why is this the case?
> >
> > http://httpd.apache.org/dev/release.html
> > http://cayenne.apache.org/release-guide.html
> > http://incubator.apache.org/servicemix/release-guide.html
> > http://activemq.apache.org/release-guide.html
> >
> > I do note that the Incubator release guide states "Different options or
> > opinions are encouraged.". If options are offered (and I can't say that
> > there are without reading the detail) then we need a place to document
> which
> > are chosen for Tuscany releases.
> >
> > Simon
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Release process & guide & checklist, was Fwd: [VOTE] Release SDO Java 1.0-incubating
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
I'd like the release guide if the steps we follow are a bit different
than what is normally done or if there are some variations to how we
perform some steps. But if we were just about going to rephrase all
of what has already been said somewhere else I'd prefer just about
having a pointer from Tuscany. Maybe a good begining to all of this
could be to have our release guide and link to the information that is
available. Then as we get to review and apply that we could flesh our
guide.
Having said that, I'd like us to have a 'release review checklist'
that enlists the bunch of things that need to be reviewed in a RC
including things like testing out the binary distro before the source
distro. etc.
- Venkat
On 7/24/07, Simon Laws <si...@googlemail.com> wrote:
> snip..
>
> >
> > There's already lots of doc about doing releases in the ASF - on the ASF
> > main dev pages and within the Incubator site etc.
>
>
> The problem with there being lots of docs is that there are, ahem, lots of
> docs. Where is the definitive set of guides that provide the detail required
> to release Tuscany for someone, like me, who hasn't done it before? Possibly
> an impossible question to answer as you don't know what I don't know and I
> don't know what you do know so our view of what is an acceptable level of
> detail probably differs. Here are the top level guides I found.
>
> http://www.apache.org/dev/#rreleases
> http://incubator.apache.org/guides/releasemanagement.html
>
> I can't say whether the above links are satisfactory as I haven't been
> through the process but I agree that we should propose updates if they are
> found to be wanting. For example, a discussion of RAT.
>
> For consistency I would expect to see all the keystrokes recorded that are
> required to produce and distribute a release. The fewer the better so, yes,
> more automation would be good. I expect automation does not completely
> remove the responsibility to check the release against release criteria,
> e,g, legal, but gives a good indication of what is required to make the
> release happen. Again anything we can do to automate these checks is good.
>
> I don't expect that release is a process that should involve a lot of
> imagination on our part other than in providing more automation of the
> required steps. To put it another way is there anything specific we have to
> do for Tuscany that would not be included in the general guide? I note that
> many projects do have release guides. Why is this the case?
>
> http://httpd.apache.org/dev/release.html
> http://cayenne.apache.org/release-guide.html
> http://incubator.apache.org/servicemix/release-guide.html
> http://activemq.apache.org/release-guide.html
>
> I do note that the Incubator release guide states "Different options or
> opinions are encouraged.". If options are offered (and I can't say that
> there are without reading the detail) then we need a place to document which
> are chosen for Tuscany releases.
>
> Simon
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Release process & guide & checklist, was Fwd: [VOTE] Release SDO Java 1.0-incubating
Posted by Simon Laws <si...@googlemail.com>.
snip..
>
> There's already lots of doc about doing releases in the ASF - on the ASF
> main dev pages and within the Incubator site etc.
The problem with there being lots of docs is that there are, ahem, lots of
docs. Where is the definitive set of guides that provide the detail required
to release Tuscany for someone, like me, who hasn't done it before? Possibly
an impossible question to answer as you don't know what I don't know and I
don't know what you do know so our view of what is an acceptable level of
detail probably differs. Here are the top level guides I found.
http://www.apache.org/dev/#rreleases
http://incubator.apache.org/guides/releasemanagement.html
I can't say whether the above links are satisfactory as I haven't been
through the process but I agree that we should propose updates if they are
found to be wanting. For example, a discussion of RAT.
For consistency I would expect to see all the keystrokes recorded that are
required to produce and distribute a release. The fewer the better so, yes,
more automation would be good. I expect automation does not completely
remove the responsibility to check the release against release criteria,
e,g, legal, but gives a good indication of what is required to make the
release happen. Again anything we can do to automate these checks is good.
I don't expect that release is a process that should involve a lot of
imagination on our part other than in providing more automation of the
required steps. To put it another way is there anything specific we have to
do for Tuscany that would not be included in the general guide? I note that
many projects do have release guides. Why is this the case?
http://httpd.apache.org/dev/release.html
http://cayenne.apache.org/release-guide.html
http://incubator.apache.org/servicemix/release-guide.html
http://activemq.apache.org/release-guide.html
I do note that the Incubator release guide states "Different options or
opinions are encouraged.". If options are offered (and I can't say that
there are without reading the detail) then we need a place to document which
are chosen for Tuscany releases.
Simon
Re: Release process & guide & checklist, was Fwd: [VOTE] Release SDO Java 1.0-incubating
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 7/24/07, ant elder <an...@apache.org> wrote:
<snip>
> - 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
i've talked to brett before about integrating parts of RAT into the
maven release plugin
jochen has developed a maven plugin but being able to pass or fail
relies on more function being added to RAT
i had hoped to be able to find more cycles now but IMAP is tough and a
personal priority (since i use it to read my mail) so i'm not sure
when i'll be able to find the cycles. SO any help on RAT would be
gratefully accepted ;-)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Release process & guide & checklist, was Fwd: [VOTE] Release SDO Java 1.0-incubating
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 7/24/07, ant elder <an...@apache.org> wrote:
> 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.
IMHO when you use the RC method, having multiple RCs does not indicate
a failing. it really indicates that committers are carefully vetting
the candidates.
> 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).
IMO there's a balance to be struck. each project develops it's own
house style for releases. recording this house style allows more
developers to act as release managers.
IMHO automation is difficult to perfect. recording the house style
helps to manage the automation process. though a worthy investment, it
is best to adopt an incremental approach. automate more but do not put
off automation or releases to wait for the other.
the incubator release guide is the next document on my personal hit
list. i'd like to see a menu of ways that releases are done at apache
allowing project to pick and choose their house style by combining a
number of well documentation alternatives. it'd be great if the
tuscany team would consider feeding any release documentation they
develop back into the release guide and create a style guide linked to
the details.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Release process & guide & checklist, was Fwd: [VOTE] Release SDO Java 1.0-incubating
Posted by ant elder <an...@apache.org>.
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 <lu...@gmail.com> 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 <an...@apache.org>
> Date: Jul 23, 2007 2:48 AM
> Subject: Re: [VOTE] Release SDO Java 1.0-incubating
> To: tuscany-dev@ws.apache.org, kelvin@thegoodsons.org.uk
>
>
> On 7/21/07, kelvin goodson <ke...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>