db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: [jira] Commented: (DERBY-2847) More clarification issues for the release notes.
Date Sat, 07 Jul 2007 15:02:31 GMT
Myrna van Lunteren wrote:
> On 7/6/07, Daniel John Debrunner (JIRA) <jira@apache.org> wrote:
>> What's the ant target to build the release notes [...]
> 
> See: 
> http://wiki.apache.org/db-derby/ReleaseNoteProcess#head-1562c977bce7878313b51f6e55a9856bc2b09801

> 
> 
> The step that's currently  most troublesome is to generate the reports
> out of JIRA.
> part of it can be accomplished by:
> java org.apache.derbyBuild.JiraConnector
> (But this gives everything, and I've modified the release notes
> generator to strip out test issues, for example.)
> Theoretically, this could be one step...

I assume you are going to commit those changes back in. A release needs 
to be in a state where someone else can build it using the same source 
as is in the release. I hope there's no manual editing of the release notes.

> 
>> [...](and the one to build a complete release)?
> Assuming you've got the maintversion.properties(for the version
> number) and release notes in order (or don't care about them):
> - build the docs or get them from the apache derby site
> - copy tools/ant/properties/packaging.tmpl to
> tools/ant/properties/packaging.properties and set the location for the
> docs; set your md5 executable preferences
> - comment out any sane settings in your ant.properties
> - follow the steps currently in the 2nd step 7 of :
> http://wiki.apache.org/db-derby/DerbySnapshotOrRelease
> i.e.:
>  svn up


>  ant clobber
>  rm -rf jars javadoc snapshot  # really clean
>  rm tools/release/*.zip tools/release/*.tar.gz  # really,
>  rm tools/release/*.md5 tools/release/*.asc     # really clean

One issue here is the number of different locations that the Derby ant 
targets build into. I just set up a new project with ant and everything 
becomes much easier if there is a single build folder. So this project 
builds into
    build/classes
    build/lib
    build/release.jar
etc.

Thus the clean operation is a simple remove on the build folder.

>  ant sane ; ant all ; ant buildjars   # for lib-debug
>  ant clobber
>  ant insane
>  ant -Dsane=false snapshot
>  ant publishedapi
>  cd tools/release
>  ant release
> (for actually creating a full release this needs to be followed by ant
> sign and then one still needs to build the ui and doc plugins using
> eclipse.)

What does building using 'eclipse' mean? I assume one can build plugins 
from an ant target without launching the IDE.

> Most of these except the ant sign and eclipse plugin generation can be
> put in one ant target but as it should stop when any of the steps
> fail, or when sane is set in ant.properties, or the docs are not set,
> or md5 doesn't work, or...(?) and probably should be made to build the
> docs if it can figure out the source location it needs a little more
> work than I'm currently willing to put into it. This is DERBY-2573.

Just FYI that by using ant as intended (via dependencies) targets fail 
if a dependency fails, so that's actually the easier mechanism. Derby's 
build.xml files tend to not take this approach. For example the Derby 
'snapshot' target uses ant call to build 'insane', 'all' 'buildjars' 
etc., that's the wrong approach, a failure in those will not be pushed 
to the top level. Instead is should just depend on those targets.

In this new project I have an ant target called 'release'. It builds a 
release from scratch, including compiling java code, running junit 
tests, running some java code, building jars and then running tests 
again against the jars. If anything fails, then the ant fails and no 
release is built.

It would be good for us to get this mindset for the release process, if 
it can't be done through ant then it can't be part of the release 
process. I see that the release managers seem to have to struggle to 
build the release artifacts, that doesn't encourage others to be release 
managers, enable release often or allow regular testing of the release 
process. I'm envious when I see other open source projects build a 
release quickly and move straight to a vote, even when a new committer 
performs the release manager role.

I'd be willing to help out on some of these ant targets.

Dan.

Mime
View raw message