On Tue, 2007-01-30 at 14:53 -0800, Will Glass-Husain wrote: > Hi all, > > Reluctantly, I vote -1. > > I tested the release. It compiled fine, ant test ran fine under JDK > 1.5 and 1.6, worked with Velocity Tools 1.2. But when I checked all > the hyperlinks, the anakia page was missing. There's an error when > generating the page and it was left out of the distribution [1]. > > I'm concerned about two things. I'm concerned about a prominent bad > link on the main menu, and I'm concerned the last minute "vote on the > final release" might not have uncovered additional problems. We've a > chance to make a major impression on the Java world with this > prominent release and I want this to be very smooth installation for > both new users and the typical existing user who wants to upgrade. > > My recommendation is to delay the release until there's time to fix > these doc issues and for more thorough testing. Mid-March seems fine. > For the "shallow bugs" theory to work, we need to issue a "release > candidate" that everyone can work with. This doesn't need to be an > actual release, just a binary distribution we can test. After a few > weeks we should be assured the details are 100% set. > > Incidentally, I disagree with Henning's comment that the beta2 had no > errors. Actually, beta2 had a serious error in the build process in > which "ant test" failed when run from the actual distribution. It > worked from the source distribution but not the released package. No > one found this problem for a month. > > I can't adequately express my admiration of Henning's efforts in the > last 6 months to get this out. This must be frustrating. I take > responsibility myself for not thinking through the implications of the > release process when Henning proposed a month ago we issue a release > at the end of January. > > However, the good news is that the recent momentum was effective. We > are right at the doorway to a new release with many new features. The > code is branched and close to perfect. Docs are set, readme is > present. With a little more checking (and fixing minor issues like > this one), we can type "ant dist" in early March and create the new > release.
I did discuss this in some depth with Will on IRC. He explained me his reasons for the vote in depth I respect them. Here is my response: - The problem with the anakia.html file is apparent and obvious. So we have a single file for a quite obscure part of Velocity missing. It is fixed on the site (http://velocity.apache.org/engine/releases/velocity-1.5/anakia.html) so if anyone is really looking for this file and can not find it in the downloaded distribution, it is available online. To me, this is no show stopper. It is a wart. We have a number of them (I can readily think of at least one more broken link on the bundled pages). - The release feels "rushed". As I wrote, yes in part it is because I want to get it out before end of January. We have been dragging that release for so long that we might make the vaporware top 10 at some point. I'd like to get over with it. If we have warts, we can release 1.5.1 which fix them. Aiming for perfection IMHO does not cut the cake. Good is enough and we can always do the next release. We can find a reason not to release every time we try. - The issues we have are *solely* with documentation. No code is involved. - Re-releasing 1.5 is IMHO not possible. We have rolled tarballs and jars which have been available from http://people.apache.org/dist/velocity/1.5/ Some people are bound to have downloaded them and they might even spread. We can denounce them as "not officially released" but if we re-roll 1.5 tarballs, we will end up with bug reports against bogus versions. Telling me that I did a lot of work is nice. I know it. Velocity did cut seriously into my spare time lately and I want to spend this time for coding, not doing release and documentation chores. There has not much response been in terms of helping with docs and while most people are already talking about "the grand new Velocity 2.0", we want to get an actual release for 1.x first. BTW: I don't actually buy into the "smooth transition" argument anyway, however I can not really reinforce it. If you have an app that uses 1.4 or 1.3 for a long time and you just drop 1.5 in, you are in for a surprise. There is always dependency upgrading (which we could have stated more prominently in the release, but we do have it on the web site now (http://velocity.apache.org/engine/devel/upgrading.html, once the mirror caught up), so adding that link in the announcement is IMHO fine. As a compromise, I'd like to propose to keep the 1.5 release and call it "Release candidate" in the same way as httpd calls it's releases x.y.z and assigns them "levels of quality" such as (Alpha) (Beta) (Release Candidate) (General Availability). So this would then be Velocity 1.5 (Release Candidate) with probably Velocity 1.5.1 (General Availability) following. This would mean that we reduce our planned 'press campaign' to an announcement on the dev list and the RSS feed and run the real thing for 1.5.1. I will not release if we have a -1 vote even if we do have three PMC +1 votes. I know the 'Apache rules' would back me here, but I would feel uncomfortable to do this without unanimous consent from the PMC members. Will felt strong enough about this to not just abstain but to vote -1, so we should try to resolve this and get him to retract his vote. I did pull the release archives from people.apache.org. If we can resolve this on short notice, good. If not, we are basically stuck with Mid-March as the next possible release date (and a third vote) if I should do the release or someone else stepping up as release manager. I'd like to hear opinions from others to that. I'd also like to encourage you to lobby Will to withdraw his -1 :-) Best regards Henning --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
