Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <43887C35.8080501@sbcglobal.net>
Date: Sat, 26 Nov 2005 07:16:05 -0800
From: Kathey Marsden <kmarsdenderby@sbcglobal.net>
User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)
MIME-Version: 1.0
To: Derby Development <derby-dev@db.apache.org>
Subject: Comments/questions  on release instructions
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


Thanks to Andrew   for making up the snapshot or release
instructions,http://wiki.apache.org/db-derby/DerbySnapshotOrRelease.   
I am really impressed that he  figured this all out the first time and
am glad there is now this reference for other committers who might want
to take on the release manager job next time.

For 10.1.2.1, I have not yet done step 18 for Maven  or step 20 to tag
the release (see questions below ) but will do those  this week.  Here
are my notes from following the  release process for 10.1.2.1  otherwise.

General
I think it would be good for the clobber target to clean up the jars and
other release target files or provide an alternate target for cleanup.
I think the release process is still a  little fragile, especially with
regard  to  generating the release pages.    Having gone through it
once, I think I could muddle through it again except for the final edits
of the html file  (step 17) which still seem pretty mysterious to me. 


Step 2
There seems to be some sort of problem with the sanity state.

After ant clobber, rm -rf jars, rm -rf snapshot  no apparent problematic
files, ant -Dsane=false snapshot  seemed to sometimes build the jars to
the sane jar directory and yield the following error.
....
   [delete] Deleting directory D:\svn\opensource\10.1\javadoc\sourcedir
    [mkdir] Created dir: D:\svn\opensource\10.1\snapshot

BUILD FAILED
D:\svn\opensource\10.1\build.xml:1287:
D:\svn\opensource\10.1\jars\insane not found.

A reliable  workaround was to run
ant insane
before ant -Dsane=false snapshot.


Step 6
 
I happened to notice that several committers do not have their public
PGP/GPG key is in the KEYS file.  Might be good to add.

Step 8

This step suggests using the docs at /www/db.apache.org/derby/docs/.  It
was not clear to me whether this would have the latest bug fixes.  Does it?

Step 9. 
Again,  I had to do "ant insane" before "ant -Dsane=false snapshot"
On Windows 2000 using MKS 6.2.a,  I could not get the sign target to
work as it hung apparently waiting for input but did not like my pass
phrase and did not prompt for what it did want.  Running with ant
-verbose I could see that it did not advance after entering my pass
phrase.  I had to just sign and generate the md5 files  with a script.

In general if we get the sign target working I think it would be better
for the target to use md5sum instead of md5 as it is more widely available.

Step 10

Note: I did not build the ui plugin. Susan built it for me

step 16

The plugins are built with the build number in the name. That needs to
be removed to match the convention of the other files on the release
pages or perhaps the build should change.

There is no "current" link for the plugins is that ok?

 
step 17

There seemed to be a lot of gotcha's in this step which was especially
problematic because right now it looks like the cgi scripts have to be
tested live on the website and there is an hour delay for them to get
there.  Below are  the issues  I hit.  Some are just forrest newbie
issues I am sure.

The cgi file won't build until it is linked from the downloads page, so
I needed to do that up front.  (I had hoped to prepare the page and link
in at the last minute.)

I had  to add the html file to  src/documentation/conf/cli.xconf. to get
it to build.
Near 310 of that file, I had to  add: <uri type="append"
src="releases/release-10.1.2.1.html"/>

Once the html file did build it went to  <forrest install
directory>/main/site/releases and  I needed to copy it to to
build/site/release manually. This is a bug in forrest apparently.

For the new cgi files, the svn executable property needs to be set (e.g)
svn propset svn:executable ON release-10.1.2.1.cgi

When I built  forrest it build a bunch of unneeded stuff in
build/site/papers and build/site/skin.  I had to  revert those files. 
In the end I checked in:
   build/site/releases/release-10.1.2.1.cgi 
   build/site/releases/release-10.1.2.1.html    (copied from the install
location where it builds)
   src/documentation/content/xdocs/releases/release-10.1.2.1.cgi  
   src/documentation/content/xdocs/releases/release-10.1.2.1.html 


There are problems with the html file as forrest changes it.  The
comments need to be in a certain format which forrest messes  up. 
Andrew edited this for me in a hurry.  This file stays checked out with
the changes in /www/www.apache.org/dist/db/derby.  This process  needs
to be better understood and documented or  much better somehow eliminated.

I could not  test the cgi scripts on my local machine, but after svn
update on people.apache.org I could look at them right away by setting
my  http proxy setting, see
http://www.apache.org/dev/project-site.html.  Still downloads did not
work using the proxy, although the cgi page did display.   


Step 18
I think that to understand this step one would  have to look in detail
at the ant targets.
 It  would be good to clarify and provide more detail providing an
example, a reference to information on the maven repository or an
explanation of what is being copied to/from where.


Step 20
I think there is a problem with this format or perhaps I misunderstood
it. An example would be good.
Do doc and code need to be tagged separately?

svn copy -r {rev} https://svn.apache.org/repos/asf/db/derby/{trunk_or_branchname}/ https://svn.apache.org/repos/asf/db/derby/tags/{version}/

I tried the two below and then decided I better stop guessing.
svn copy -r 330608 https://svn.apache.org/repos/asf/db/derby/10.1/
https://svn.apache.org/repos/asf/db/derby/tags/10.1.2.1/
svn copy -r 330608
https://svn.apache.org/repos/asf/db/derby/code/branches/10.1/
https://svn.apache.org/reepos/asf/db/derby/tags/10.1.2.1/

Step 21

I think for either  major/minor release we need a branch but this seems
late in the process. I think it makes  sense to make the branch right
before  the first release candidate, so that the beta flag can be turned
off.  Then the version can be bumped on the trunk and development can
continue.


Step 22

For a bug fix release, the version should have already been bumped as
soon as the release candidate was posted, so no need to bump the last digit.
For major/minor releases, the 1st or 2nd digit should be bumped
appropriately after making the branch, based on plans for the next
release.  This could be included in the step to make the branch I think.