Re: Towards Ant 1.5 (Re: Bug fixes to 1.4.1)

[Magesh Umasankar <um...@apache.org>]

From: "Conor MacNeill" <co...@cortexebusiness.com.au>


> Magesh Umasankar wrote:
>
> > From: "Steve Loughran" <st...@iseran.com>
> >
> > * 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.

ok.  We are making some noticeable progress
already, thanks to Diane, Stefan, Erik and Steve...

>
>
> > 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.

Thanks for starting up on this, Conor.

>
> 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 think it would be great if we can document this
piece too.  For example details on how to create
the branch, how to apply patches to a branch and how
to do multiple merge backs.  If we point to a link that
discusses this in detail, that would be helpful too.
I will try to identify some such link also, meanwhile.

>
> 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.

ok.  Do we have to take care while tagging, by
avoiding tagging of proposal tree, etc?

>
> 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.

Do we actually tag 1.6Alpha?  I don't understand the
second part wrt 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
> easier.
>
> I then sign the distribution files using the following simple script
> #!/bin/sh
> for i in distribution/*
> do
>          echo "Signing " $i
>          gpg -a -b $i
> done
>
> 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.
>   Strange.

What ground work should be done to sign?
In other words, where must public key be posted?

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

ok.

> 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.

1.5Beta1 preferred?

>
> 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.

ok.

>
>   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.

Where do you look up the number of hits?

>
> 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
> process.
>
> 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.

:-))  That reminds me to say another 'Thank You' to
you for taking care of releasing 1.4

>
>
> > 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
>
> check_for_optional_packages:
> Unable to load class java.lang.CharSequence to set property jdk1.4+
> Unable to load class com.ibm.bsf.BSFManager 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 :-)

In the next few days, I will compile what you
have provided into a document and add it to cvs...

>
> Conor
>

Thanks,
Magesh

************************************************
*  Office: A place where you can relax after   *
*  your strenuous home life.                   *
************************************************



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>