You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Kathey Marsden <km...@sbcglobal.net> on 2005/11/26 16:16:05 UTC
Comments/questions on release instructions
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.
Re: clobber target
Posted by Mike Matrigali <mi...@sbcglobal.net>.
I can second this, when debugging a file I tend to just use the classes
and rebuild over/over the same .java file. There use to be better
support with previous build systems to optimize this case - but you
had to know what you were doing since if you didn't run the build from
the top you might change a file that some file elsewhere in the system
depended on. Thus when I am done locally debugging I always to a full
build.
Daniel John Debrunner wrote:
> Bryan Pendleton wrote:
>
>
>
>>What I don't understand is a target that *cleans* only the classes, and
>>not the jars. I think it makes it too easy for the distracted developer
>>to accidentally run with the wrong code, by using the old jars.
>
>
> I think some of it is history with the product. The Cloudscape jars,
> when it was a closed source product, took a long time to build and the
> process needed a machine with a lot of memeory. This was due to the
> obfuscation process. Thus developers typically did not build the jars,
> only the classes, and the build scripts were set up to reflect that.
>
> Dan.
>
>
>
Re: clobber target
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Bryan Pendleton wrote:
> What I don't understand is a target that *cleans* only the classes, and
> not the jars. I think it makes it too easy for the distracted developer
> to accidentally run with the wrong code, by using the old jars.
I think some of it is history with the product. The Cloudscape jars,
when it was a closed source product, took a long time to build and the
process needed a machine with a lot of memeory. This was due to the
obfuscation process. Thus developers typically did not build the jars,
only the classes, and the build scripts were set up to reflect that.
Dan.
Re: clobber target
Posted by Bryan Pendleton <bp...@amberpoint.com>.
John Embretsen wrote:
>> 2) I'm surprised by the concept of removing the class files but not
>> removing the jar files; I have trouble thinking of situations in
>> which I'd want to rebuild the class files but not rebuild the jars.
>
> I think some developers feel that it is more convenient to include the
> classes directory in their "sandbox classpath" instead of all the derby
> jars. This means that the jars don't have to be re-built every time the
> developer wants to try something out, thus saving some time (albeit not
> much).
I understand having a target that builds only the classes, and not the
jars. I agree that it's very convenient to point my classpath at the
classes directory.
What I don't understand is a target that *cleans* only the classes, and
not the jars. I think it makes it too easy for the distracted developer
to accidentally run with the wrong code, by using the old jars.
Andrew's proposed change to "ant clobber" to clean the jars as well as
the classes will address my need; I just need to train myself to start
using "ant clobber".
thanks,
bryan
Re: clobber target
Posted by John Embretsen <Jo...@Sun.COM>.
Bryan Pendleton wrote:
> 2) I'm surprised by the concept of removing the class files but not
> removing the jar files; I have trouble thinking of situations in
> which I'd want to rebuild the class files but not rebuild the jars.
I think some developers feel that it is more convenient to include the
classes directory in their "sandbox classpath" instead of all the derby
jars. This means that the jars don't have to be re-built every time the
developer wants to try something out, thus saving some time (albeit not
much).
> I wish I just had a simple target that said: "blow everything away"
> and another that said "build everything that matters". Instead I
> often find myself doing awkward things like:
>
> ant clobber; ant; ant testing; ant buildjars
>
> Am I just missing a simple incantation?
I don't think there is one...
I routinely use "ant clobber", "ant all" and "ant buildjarsclean".
The latter target removes the old jars and builds new ones (I have seen
issues (jars not being properly updated) after using "buildjars" without
removing the old jars first).
The "all" target inlcudes "testing", thus saving you one command ;)
What I find the most counter-intuitive about this is that the "all"
target does not include building the jars.
--
John
Re: clobber target
Posted by Bryan Pendleton <bp...@amberpoint.com>.
> "clean" removes the contents of the build output directory only.
...
> "clobber" also removes generated files outside of the build
> output directory
Thanks for the good explanation. Two follow-ups:
1) It seems like there are build products (the jars and the
javadoc, at least, perhaps others?) which are not removed by
either "clean" or "clobber". That strikes me as odd; my
expectation when running Ant is that there is some target,
typically "clean", which removes *all* the artifacts that
got built by the Ant scripts.
2) I'm surprised by the concept of removing the class files
but not removing the jar files; I have trouble thinking of
situations in which I'd want to rebuild the class files but not
rebuild the jars.
In general, Derby seems to build so quickly for me (rarely more
than a minute or so for a complete build on the machines that
I have routinely available), that my initial reaction to the build
scripts has been: "too much complexity". I wish I just had a simple
target that said: "blow everything away" and another that said
"build everything that matters". Instead I often find myself doing
awkward things like:
ant clobber; ant; ant testing; ant buildjars
Am I just missing a simple incantation?
thanks,
bryan
Re: clobber target
Posted by Andrew McIntyre <mc...@gmail.com>.
On 12/6/05, Bryan Pendleton <bp...@amberpoint.com> wrote:
> Somewhat of a tangent, but could you take a few moments and explain
> the intent behind having both "clobber" and "clean"? I don't understand
> why it isn't sufficient just to have "ant clean". When are we supposed
> to use "clean" versus "clobber"?
"clean" removes the contents of the build output directory only.
Running the clean target is useful if you know you don't need to
regenerate the sanity state or the parser files but you want a full
recompile. "clobber" also removes generated files outside of the build
output directory like the sanity state properties, the parser files
generated by javacc and the class size catalog. It seems to me that
the jars, being generated files and living outside the build output
directory, would be a logical candidate for addition to the clobber
target.
Personally, I almost always clobber and almost never clean. Although,
with the jars and javadoc added to clobber, I would probably use the
clean target more often, as sometimes I don't want to blow away the
jars or javadoc when doing a full recompile.
Also, one could argue that the generated files like the parser files
should move to the clean target to more reflect the general use of
that target name, and having clobber take care of the higher-level
build output like jars, javadoc, etc.
andrew
Re: clobber target
Posted by Bryan Pendleton <bp...@amberpoint.com>.
Andrew McIntyre wrote:
>>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.
>
> If there are no complaints, I'll add the jars and javadoc output
> directories to the clobber target.
Somewhat of a tangent, but could you take a few moments and explain
the intent behind having both "clobber" and "clean"? I don't understand
why it isn't sufficient just to have "ant clean". When are we supposed
to use "clean" versus "clobber"?
thanks,
bryan
Re: Comments/questions on release instructions
Posted by Andrew McIntyre <mc...@gmail.com>.
On 11/26/05, Kathey Marsden <km...@sbcglobal.net> wrote:
> For 10.1.2.1, I have not yet done step 18 for Maven
Looks to be taken care of by Jeremy. Thanks, Jeremy!
> or step 20 to tag the release (see questions below )
Taken care of by me. I left out the 'code' part of the URL. I'll
update the wiki.
> 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.
If there are no complaints, I'll add the jars and javadoc output
directories to the clobber target.
> 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.
Hoepfully by the next time we have a release, we will be using Forrest
0.8 which fixes the underlying issue, FOR-480.
> Step 2
> There seems to be some sort of problem with the sanity state.
Filed DERBY-744 for this.
> 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?
I clarified that this is only an option for the trunk.
> Step 9.
> 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.
The instructions do say to edit packaging.tmpl to provide appriopriate
defaults for your system. The various options of md5 / md5sum are not
standardized across platforms.
> 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.
I'll leave this to the Eclipse plugin folks. I thought that Eclipse
plugin build numbers were somewhat standardized among Eclipse plugins.
> There is no "current" link for the plugins is that ok?
It's ok, but it wouldn't hurt to add one, either.
> step 17
Thanks for all the feedback, I've added all of this information to the wiki.
> Step 18 (Deploy to Maven repository)
Jeremy, or anyone familiar with this process, do you think you could
flesh out this section a little more?
> 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?
Yes, updated the wiki with the proper URLs.
> 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.
Yes, this is true. I've moved that section up and added a note about
the beta flag.
> 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.
Yep, fixed on the wiki.