ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <>
Subject Re: Towards Ant 1.5 (Re: Bug fixes to 1.4.1)
Date Thu, 28 Mar 2002 09:25:17 GMT
Magesh Umasankar wrote:

> From: "Steve Loughran" <>
> * Conor feels that we need to get the number 
>   of 'bugs' down to around 30...

This has been my target in previous releases. It does exclude enhancement 
requests :-) although these too should not be left to linger, IMHO. This is not 
a hard and fast rule, of course, just an objective. In fact, for this coming 
release, it may be judged not to be a practical objective. In the end, a vote 
will decide if the release should go ahead.

> And while we are on the topic:
> Conor, do you have a list of 'Things to do' 
> to make a release?  If so, please post it.
> Even a rough sketch would help - we can
> then iteratively improve upon it to form
> an exhaustive document...

OK, let me start that process by noting down some ad-hoc thoughts on how I have 
built the previous couple of releases. This is just how I go about it and need 
not be binding on others.

I usually start by proposing a release plan as a vote. This will set out the 
timetable for the release under ideal circumstances. The level of bugs reported 
can delay things. Generally I give a few weeks to "close" the source tree to 
further changes so people can finalise contributions, etc. At this time, the 
first beta will be cut and there will be then a period of beta testing, usually 
1 month but this should be flexible.

Note that any mention of a deadline causes a flood of bug fixes, new tasks, etc. 
This needs to be managed as best it can. Some fixes will be applied, others held 
over. I try to make this clear in the release plan. You can probably dig up the 
previous ones in the archives. The committers and particularly the release 
manager will need to make judgement calls here. Anything too "big" is likely to 
be held over.

Once the freeze date arrives, my practice in Ant 1.3 and Ant 1.4 has been to 
create a branch for the release builds. Ant 1.1 and Ant 1.2 did not do this but 
it was somewhat more practical in those days to hold up development during the 
beta testing period. Of course you will need to be comfortable in handling CVS 
branches with mutliple merge-backs to the main branch and even selected merges 
from the the main branch to the release branch.

I have labelled such branches ANT_13_BRANCH, ANT_14_BRANCH, so the next branch, 
if this practice is continued would be ANT_15_BRANCH.

Once the branch is setup, the version numbers in CVS are changed. On the branch, 
the build.xml version becomes 1.5Beta1 while the main branch is updated to 
1.6alpha. I seem to recall that some of the documentation files also need to be 
updated to point to the right areas of Ant's website.

Next I bootstrap and build, run the tests and then build the distribution on the 
branch. It is important that this be a clean build. I would label this with a 
tag ANT_15_B1. In fact I generally use heaps of CVS labels as it makes merging 

I then sign the distribution files using the following simple script
for i in distribution/*
         echo "Signing " $i
         gpg -a -b $i

I try to do this on Linux since the gpg signatures I generated on Windows caused 
some PGP users problems verifying signatures even though I could verify them OK. 

You now have the beta distribution ready to go. I usually bundle it up into a 
tar file and scp to my apache account.

While that is uploading (slowly over my dialup), I convert the WHATSNEW file 
into HTML for the README file on the website. You can see the previous release 
directories for examples of these files. I try to add instructions and warnings 
(GNU tar format issues, etc).

Once this is uploaded, I unpack things, create the release directory, something 
like v1.5Beta1, push the release and README files into this directory.

Next the available release tags in BugZilla need to be addressed. I create a new 
  tag 1.5Beta1 and a 1.6alpha. I will usually assign all existing 1.5 alpha bugs 
to one of these release labels.

Once that is done, I do a test download to make sure everything is OK. If it 
looks OK, I announce it on ant-dev and ant-user. After a few days pass and there 
are no major problems a wider announcement is made (main jakarta websire, 
general and announce lists, etc).

As problems in the beta are discovered, there may be a need for one or more 
subsequent betas. The release manager makes this call. Each time, the versions 
are updated and the above process is repeated. We try not to have too many betas.

  I noticed an interesting effect in the last release, it seemed that very few 
people really tried out the beta. The number of downloads of Ant 1.3 continued 
to outstrip the 1.4Beta by a significant margin. Once 1.4 was released however, 
a lot of people jumped into it and we found some issues which resulted in the 
1.4.1 release. It would be good to avoid this if we can.

When the final beta is considered OK, a vote is proposed on ant-dev to 
officially adopt the latest beta as the Ant 1.5 release. If it is passed, and it 
usually does, this would be labelled ANT_15 and built similarly to the above 

Now and perhaps during previous betas any changes on the branch must be merged 
back into the tree.

At this point in time, the release is done and announcements are made. You can 
now reacquaint yourself with your family and friends.

> I am shying away from even trying to build
> all of Ant because I do not have access to
> most of the tools and APIs that make up the
> optional stuff.  Jon said he had some 'dummy'
> APIs, though not exhaustive...

Most of Ant can be built from available libraries. If you have done a Gump run, 
you will have most of the available jars required. I run the first coupld of 
builds with verbose and check what properties are not being set like this

Unable to load class java.lang.CharSequence to set property jdk1.4+
Unable to load class to set property bsf.present
Unable to load class netrexx.lang.Rexx to set property netrexx.present

This will point you to the libraries you need to add.

> *If* I were able to easily build Ant as a 
> whole, complete with optional tasks, etc.,
> I would volunteer to try getting a release 
> out.

This is a problem, especially when the resulting jars need to be signed. I would 
be somewhat reluctant to sign a jar containing code I had not compiled myself.

Oh, I may have forgotten a few things :-)


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message