From: "Conor MacNeill" <[EMAIL PROTECTED]>
> Magesh Umasankar wrote: > > > From: "Steve Loughran" <[EMAIL PROTECTED]> > > > > * 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
