Re: Velocity Debugger
Hi Will, Well, we have used Velocity, in a generator application code for generating J2EE code ... And I can tell you that some velocity template are quite big enougth to justify the use of a debugger ;-)) I have done a eclipse RCP application to wrap our generator core, and then I asked me, how it will be great to have a eclipse debugger for the RCP application. That's why I'm interrested to have this velocity debugger !! Well, I began to work on that, but I have touch the velocity 1.4 code, and put some code in the render methods, and I know that you have generated with JavaCC, but I've no time to do it with JavaCC, that's why I came to you to have your state of mind about it !! Hasta luego Bruno Will Glass-Husain-2 wrote: Sure, that might be interesting to see. But aren't templates usually simple enough that a debugger is overkill? Having said that, if you wanted to work on this, we'd welcome a link to it or a contribution on the Wiki. best, WILL On 1/29/07, bguedes [EMAIL PROTECTED] wrote: Hi Will, Well in having a debugger, I was thinking in a debugger like the Pnuts one !!! For having, per example, a eclipse debugger to stepping in a velocity template ... Well, it seems to me that for having a debugging mecanism, we have to modify the render() methods of SimpleNode class and the child classes also like the Directive one !! Well, what about doing one debugger ??? Sincerely Bruno Will Glass-Husain wrote: Not quite sure what you mean by a debugger. Do you mean a mechanism to see problems in a Velocity page? For parse errors, Velocity 1.5 throws an Exception providing the line number, column number, and template name of the error. The Click framework uses this info to do a nice job of highlighting the specific error. http://click.sourceforge.net/ In addition, there's a new event handler in Velocity 1.5 that will catch and return all invalid references, perhaps this is of help. WILL On 1/24/07, Bruno GUEDES [EMAIL PROTECTED] wrote: Hi everybody, Have you plan to create an Debugger, for exmample an Eclipse Debugger ;-) ??? Well, if possible, can I ask with somebody of the velocity task, about it ??? Have a nice day ... Sincerely Bruno - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Velocity-Debugger-tf3081966.html#a8700326 Sent from the Velocity - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Velocity-Debugger-tf3081966.html#a8706395 Sent from the Velocity - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Velocity Debugger
I wouldn't think you'd need JavaCC unless you are changing the syntax of the template language. JavaCC was originally used to generate the Node files, but after that they are hand-edited. Will On 1/30/07, bguedes [EMAIL PROTECTED] wrote: Hi Will, Well, we have used Velocity, in a generator application code for generating J2EE code ... And I can tell you that some velocity template are quite big enougth to justify the use of a debugger ;-)) I have done a eclipse RCP application to wrap our generator core, and then I asked me, how it will be great to have a eclipse debugger for the RCP application. That's why I'm interrested to have this velocity debugger !! Well, I began to work on that, but I have touch the velocity 1.4 code, and put some code in the render methods, and I know that you have generated with JavaCC, but I've no time to do it with JavaCC, that's why I came to you to have your state of mind about it !! Hasta luego Bruno Will Glass-Husain-2 wrote: Sure, that might be interesting to see. But aren't templates usually simple enough that a debugger is overkill? Having said that, if you wanted to work on this, we'd welcome a link to it or a contribution on the Wiki. best, WILL On 1/29/07, bguedes [EMAIL PROTECTED] wrote: Hi Will, Well in having a debugger, I was thinking in a debugger like the Pnuts one !!! For having, per example, a eclipse debugger to stepping in a velocity template ... Well, it seems to me that for having a debugging mecanism, we have to modify the render() methods of SimpleNode class and the child classes also like the Directive one !! Well, what about doing one debugger ??? Sincerely Bruno Will Glass-Husain wrote: Not quite sure what you mean by a debugger. Do you mean a mechanism to see problems in a Velocity page? For parse errors, Velocity 1.5 throws an Exception providing the line number, column number, and template name of the error. The Click framework uses this info to do a nice job of highlighting the specific error. http://click.sourceforge.net/ In addition, there's a new event handler in Velocity 1.5 that will catch and return all invalid references, perhaps this is of help. WILL On 1/24/07, Bruno GUEDES [EMAIL PROTECTED] wrote: Hi everybody, Have you plan to create an Debugger, for exmample an Eclipse Debugger ;-) ??? Well, if possible, can I ask with somebody of the velocity task, about it ??? Have a nice day ... Sincerely Bruno - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Velocity-Debugger-tf3081966.html#a8700326 Sent from the Velocity - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Velocity-Debugger-tf3081966.html#a8706395 Sent from the Velocity - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VELOCITY-510) Overload Macros
Overload Macros --- Key: VELOCITY-510 URL: https://issues.apache.org/jira/browse/VELOCITY-510 Project: Velocity Issue Type: Improvement Components: Documentation, Engine Reporter: Steve O'Hara Priority: Minor It would be very useful to be able to overload macro definitions with different number of/types of parameters. Many, many times there is aneed to slightly tweak an existing macro to give it new capabilities. Rather than create a new one with a different name, it would make it much neater if you could create a new one with the same name. Another way to achieve similar results would be to allow a variable number of parameters. Although not quite as formal, this would provide a reasonable alternative. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VELOCITY-512) fix dependency list in jar-dependencies.xml
fix dependency list in jar-dependencies.xml Key: VELOCITY-512 URL: https://issues.apache.org/jira/browse/VELOCITY-512 Project: Velocity Issue Type: Bug Components: Documentation Affects Versions: 1.5 beta2 Reporter: Will Glass-Husain Priority: Minor Fix For: 1.6 xdocs/docs/jar-dependencies.xml is inconsistent with xdocs/docs/build.xml. Specifically the list of dependencies is missing antlr and junit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (VELOCITY-512) fix dependency list in jar-dependencies.xml
[ https://issues.apache.org/jira/browse/VELOCITY-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen reassigned VELOCITY-512: --- Assignee: Henning Schmiedehausen fix dependency list in jar-dependencies.xml Key: VELOCITY-512 URL: https://issues.apache.org/jira/browse/VELOCITY-512 Project: Velocity Issue Type: Bug Components: Documentation Affects Versions: 1.5 beta2 Reporter: Will Glass-Husain Assigned To: Henning Schmiedehausen Priority: Minor Fix For: 1.6 xdocs/docs/jar-dependencies.xml is inconsistent with xdocs/docs/build.xml. Specifically the list of dependencies is missing antlr and junit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (VELOCITY-511) add notes on jar upgrade to README
[ https://issues.apache.org/jira/browse/VELOCITY-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen reassigned VELOCITY-511: --- Assignee: Henning Schmiedehausen add notes on jar upgrade to README -- Key: VELOCITY-511 URL: https://issues.apache.org/jira/browse/VELOCITY-511 Project: Velocity Issue Type: Bug Components: Documentation Affects Versions: 1.5 beta2 Reporter: Will Glass-Husain Assigned To: Henning Schmiedehausen Priority: Minor Fix For: 1.6 We should highlight changes in the jar dependencies. Even though this occurred Velocity 1.4 - 1.5, it would still be useful notes for user's upgrading. Suggested text: This release is a drop-in replacement for earlier versions of Velocity. No changes to your application should be required other than changes to the dependent jar files. When upgrading from Velocity 1.3, these jar file requirements have been changed * JDOM has been upgraded to 1.0 * Commons Collection has been upgraded to 3.1 * Commons Lang 2.1 has been added In addition, * Ant 1.6 or greater is required for building. * Java CC 3.2 or greater is now required for compiling parser files. * HSQLDB 1.7.1 is required for running unit tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-511) add notes on jar upgrade to README
[ https://issues.apache.org/jira/browse/VELOCITY-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen resolved VELOCITY-511. - Resolution: Fixed Added an upgrading file to the site and a notice to the README.txt Available as http://velocity.apache.org/engine/devel/upgrading.html as soon as the mirrors have picked it up. add notes on jar upgrade to README -- Key: VELOCITY-511 URL: https://issues.apache.org/jira/browse/VELOCITY-511 Project: Velocity Issue Type: Bug Components: Documentation Affects Versions: 1.5 beta2 Reporter: Will Glass-Husain Assigned To: Henning Schmiedehausen Priority: Minor Fix For: 1.6 We should highlight changes in the jar dependencies. Even though this occurred Velocity 1.4 - 1.5, it would still be useful notes for user's upgrading. Suggested text: This release is a drop-in replacement for earlier versions of Velocity. No changes to your application should be required other than changes to the dependent jar files. When upgrading from Velocity 1.3, these jar file requirements have been changed * JDOM has been upgraded to 1.0 * Commons Collection has been upgraded to 3.1 * Commons Lang 2.1 has been added In addition, * Ant 1.6 or greater is required for building. * Java CC 3.2 or greater is now required for compiling parser files. * HSQLDB 1.7.1 is required for running unit tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
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. WILL [1] [echo] [anakia] Transforming into: C:\Documents and Settings\wglass\Desktop\velocity-1.5\bin\docs [anakia] Input: anakia.xml [anakia] [anakia] Error: The end-tag for element type example must end with a '' delimiter. [anakia]Line: 117 Column: 60 On 1/28/07, Henning Schmiedehausen [EMAIL PROTECTED] wrote: Due to a misunderstanding in the vote procedure, we actually have to repeat the release vote, because we should vote only on really rolled releases. The candidate for the Apache Velocity 1.5 release is available from http://people.apache.org/dist/velocity/1.5/ Shall we release this code base as Apache Velocity 1.5 [ ] +1 Yes. [ ] 0 I still don't care. [ ] -1 No, because . Vote period is Monday, Jan 29th 0:00 MET to Wednesday, Jan 31st 0:00 MET Best regards Henning - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
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.
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On 1/30/07, Will Glass-Husain [EMAIL PROTECTED] 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]. C'mon. Anakia's documentation is anything but hard to find. I'm all for getting things right, but not for holding back releases based on one missing doc. I'd rather you let Henning release 1.5 now and release 1.5.1 yourself next week. 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. We can't cower in fear of unknown bugs. Fix what you know and care about, then let's get this thing moving again. 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. How about two betas and a test build? That's what we've had. This release has had much time to prepare. More time won't kill us, but let's not pretend things are ever likely to be 100% set. Trust me, if i cared enough, i could start combing thru the docs of almost any major project you like and find dozens of errors. Same goes for most code. Final releases will never be perfect, but the shallow bugs theory won't work if we don't get *them* out there. Far fewer people bother with release candidates and betas. 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. And it's fixed, is it not? 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. Taking responsibility in the open source world means only one thing, if you ask me. Doing the work. If you're going to take responsibility for this by re-doing this whole process to your satisfaction either by repeating the 1.5 test build and vote or by letting 1.5 go and releasing a 1.5.1, then i won't protest. But please don't just sit back and critique at the last minute. That's not just frustrating, it's obnoxious. 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. it is not close to perfect, nor will it ever be, but i believe it will get better faster if you don't obsess about it being 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. WILL [1] [echo] [anakia] Transforming into: C:\Documents and Settings\wglass\Desktop\velocity-1.5\bin\docs [anakia] Input: anakia.xml [anakia] [anakia] Error: The end-tag for element type example must end with a '' delimiter. [anakia]Line: 117 Column: 60 On 1/28/07, Henning Schmiedehausen [EMAIL PROTECTED] wrote: Due to a misunderstanding in the vote procedure, we actually have to repeat the release vote, because we should vote only on really rolled releases. The candidate for the Apache Velocity 1.5 release is available from http://people.apache.org/dist/velocity/1.5/ Shall we release this code base as Apache Velocity 1.5 [ ] +1 Yes. [ ] 0 I still don't care. [ ] -1 No, because . Vote period is Monday, Jan 29th 0:00 MET to Wednesday, Jan 31st 0:00 MET Best regards Henning - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On 1/30/07, Henning Schmiedehausen [EMAIL PROTECTED] wrote: ... 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. +1 - 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. eh... if you think so. i wouldn't say we released it even once, much less worry about re-releasing. we can call the next test build 1.5, 1.5.0 or 1.5.1, as far as i'm concerned. 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. Sorry, been busy with VelocityTools 1.3. :( 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. hmm. not thrilled about switching release procedures midway, but if you won't release Velocity 1.5 as final/GA/whatever, then i want to see some sort of release. so, i suppose i'll give this plan a: +1 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. To be honest, i'm bummed about this. I think there is wisdom in the rules. If Will feels strongly enough to -1 this, then he should feel strongly enough to address his concerns, upload a 1.5.1 test build and vote to have it released ASAP to supersede the 1.5 release. 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. Will should be able to scratch his itches quickly. Mid-march is a long time to wait for such small tweaks. If he doesn't step up with a 1.5.1 test build and vote before then, then i may take a shot at it. 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] - To
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On Jan 31, 2007, at 12:52 AM, Nathan Bubna wrote: On 1/30/07, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Jan 30, 2007, at 11:24 PM, Henning Schmiedehausen wrote: ... 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. No - that's confusing. 1.5 RC would be followed by 1.5 GA eh.. only if we're talking about a vote to just re-label 1.5. if we make changes to the distro (even for docs) and roll a new release, We didn't release this, so it doesn't matter, IMO. then we need a new number. since we're only talking about doc changes, 1.5.1 seems appropriate and would be likely to get voted as GA. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On Jan 31, 2007, at 1:52 AM, Will Glass-Husain wrote: Hi, Knew I'd be unpopular the moment I hit send. You did the right thing. This is what the oversight processes here at the ASF are about. Three quick notes. 1) don't think the changes are big. But I think the distro should be reviewed and fixed. A bad hyperlink on the main menu, in our first release in 3 years, looks sloppy and conveys an inaccurate impression of the quality of our product. 2) Unlike V-tools, we did not have a test build. Instead, the final package was created with the choice vote yes, or delay the release. I don't like it. That's why I advocate having no manual steps to re-create the release. If you are lucky, you have everything happen in HEAD. Then, tag *that*, and do misc tweaks if needed. Also, the vote or delay was simply due to special circumstances, not regular practice. 3) I'd be happy to vote +1 if we could call this Velocity 1.5rc1. But given the historic significance of this release, I urge us to release Velocity 1.5 in a professional distro without obvious errors.(no need to immediately issue Velocity 1.5.1). I think an rc1 should be as perfect as much as possible as well - calling it RC means (to me) - this is what we'd like to release, anything obvious we missed? and engage the public on it. That's what we used to do, IIRC, around here :) So yeah, this could be RC1, but to do that, I'd prefer to see something sane done like velocity/engine/branches/1.5 tags/1.5RC1 and have that released w/ RC1 in the right places. Then we wait until Henning gets back from lounging about for 6 weeks :) fix anything the community found, and go for 1.5 geir best, WILL On 1/30/07, Nathan Bubna [EMAIL PROTECTED] wrote: On 1/30/07, Will Glass-Husain [EMAIL PROTECTED] 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]. C'mon. Anakia's documentation is anything but hard to find. I'm all for getting things right, but not for holding back releases based on one missing doc. I'd rather you let Henning release 1.5 now and release 1.5.1 yourself next week. 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. We can't cower in fear of unknown bugs. Fix what you know and care about, then let's get this thing moving again. 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. How about two betas and a test build? That's what we've had. This release has had much time to prepare. More time won't kill us, but let's not pretend things are ever likely to be 100% set. Trust me, if i cared enough, i could start combing thru the docs of almost any major project you like and find dozens of errors. Same goes for most code. Final releases will never be perfect, but the shallow bugs theory won't work if we don't get *them* out there. Far fewer people bother with release candidates and betas. 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. And it's fixed, is it not? 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. Taking responsibility in the open source world means only one thing, if you ask me. Doing the work. If you're going to take responsibility for this by re-doing this whole process to your satisfaction either by repeating the 1.5 test build and vote or by letting 1.5 go and releasing a 1.5.1, then i won't protest. But please don't just sit back and critique at the last minute. That's not just frustrating, it's obnoxious. However, the
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On Jan 31, 2007, at 3:48 AM, Will Glass-Husain wrote: I thought about this a little more. There's a couple things we can do that I'd support. (1) Figure out a way to call this release something other than Velocity 1.5, e.g. Velocity 1.5rc1 and issue the release immediately. Can we do this without a 3 day vote? See my other response. Why the rush? If Henning has to go vacation, then you do the RC1 stuff, and we'll wait until he gets back for the 1.5 GA release. (2) Take a little time to make the minor fix required, then release the software. I can step up to do this over the next few days. I think Henning was concerned we'd need to rebuild the site and he's the only one that can do that. If I managed the release, I'd probably want to do Velocity 1.5rc1 first and then Velocity 1.5 two weeks later. Why is he the only one that can do the site? (3) Henning remains release manager and we wait until March for the release. We could leave the VELOCITY_1.5_BRANCH up so that the release is ready to go. We can also direct users interested in 1.5 specific features to that svn branch. Right. Do the fixes in the branch, then make a tag/1.5rc1 build, vote and release as RC1. When Henning gets back, do 1.5 GA. Advantage is that people get to beat 1.5RC1 about for a month. geir I'm sure our European community is long abed, I'll look for comments from them in the morning. WILL On 1/30/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi, Knew I'd be unpopular the moment I hit send. Three quick notes. 1) don't think the changes are big. But I think the distro should be reviewed and fixed. A bad hyperlink on the main menu, in our first release in 3 years, looks sloppy and conveys an inaccurate impression of the quality of our product. 2) Unlike V-tools, we did not have a test build. Instead, the final package was created with the choice vote yes, or delay the release. I don't like it. 3) I'd be happy to vote +1 if we could call this Velocity 1.5rc1. But given the historic significance of this release, I urge us to release Velocity 1.5 in a professional distro without obvious errors. (no need to immediately issue Velocity 1.5.1). best, WILL On 1/30/07, Nathan Bubna [EMAIL PROTECTED] wrote: On 1/30/07, Will Glass-Husain [EMAIL PROTECTED] 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]. C'mon. Anakia's documentation is anything but hard to find. I'm all for getting things right, but not for holding back releases based on one missing doc. I'd rather you let Henning release 1.5 now and release 1.5.1 yourself next week. 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. We can't cower in fear of unknown bugs. Fix what you know and care about, then let's get this thing moving again. 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. How about two betas and a test build? That's what we've had. This release has had much time to prepare. More time won't kill us, but let's not pretend things are ever likely to be 100% set. Trust me, if i cared enough, i could start combing thru the docs of almost any major project you like and find dozens of errors. Same goes for most code. Final releases will never be perfect, but the shallow bugs theory won't work if we don't get *them* out there. Far fewer people bother with release candidates and betas. 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. And it's fixed, is it not? 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
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On 1/30/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi, Knew I'd be unpopular the moment I hit send. no, no. we still like you. just not your decision. :) Three quick notes. 1) don't think the changes are big. But I think the distro should be reviewed and fixed. A bad hyperlink on the main menu, in our first release in 3 years, looks sloppy and conveys an inaccurate impression of the quality of our product. review and fix away! 2) Unlike V-tools, we did not have a test build. Instead, the final package was created with the choice vote yes, or delay the release. I don't like it. no. we did have a test build and veltools did not. test build == unreleased build to be tested then voted upon hold on, i'm dropping this email and starting another. we have to get our terms and release processes straight or we'll never find consensus. 3) I'd be happy to vote +1 if we could call this Velocity 1.5rc1. But given the historic significance of this release, I urge us to release Velocity 1.5 in a professional distro without obvious errors.(no need to immediately issue Velocity 1.5.1). best, WILL On 1/30/07, Nathan Bubna [EMAIL PROTECTED] wrote: On 1/30/07, Will Glass-Husain [EMAIL PROTECTED] 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]. C'mon. Anakia's documentation is anything but hard to find. I'm all for getting things right, but not for holding back releases based on one missing doc. I'd rather you let Henning release 1.5 now and release 1.5.1 yourself next week. 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. We can't cower in fear of unknown bugs. Fix what you know and care about, then let's get this thing moving again. 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. How about two betas and a test build? That's what we've had. This release has had much time to prepare. More time won't kill us, but let's not pretend things are ever likely to be 100% set. Trust me, if i cared enough, i could start combing thru the docs of almost any major project you like and find dozens of errors. Same goes for most code. Final releases will never be perfect, but the shallow bugs theory won't work if we don't get *them* out there. Far fewer people bother with release candidates and betas. 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. And it's fixed, is it not? 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. Taking responsibility in the open source world means only one thing, if you ask me. Doing the work. If you're going to take responsibility for this by re-doing this whole process to your satisfaction either by repeating the 1.5 test build and vote or by letting 1.5 go and releasing a 1.5.1, then i won't protest. But please don't just sit back and critique at the last minute. That's not just frustrating, it's obnoxious. 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. it is not close to perfect, nor will it ever be, but i believe it will get better faster if you don't obsess about it being 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. WILL [1] [echo] [anakia] Transforming into: C:\Documents and
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On 1/30/07, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Jan 31, 2007, at 3:48 AM, Will Glass-Husain wrote: I thought about this a little more. There's a couple things we can do that I'd support. (1) Figure out a way to call this release something other than Velocity 1.5, e.g. Velocity 1.5rc1 and issue the release immediately. Can we do this without a 3 day vote? See my other response. Why the rush? If Henning has to go vacation, then you do the RC1 stuff, and we'll wait until he gets back for the 1.5 GA release. (2) Take a little time to make the minor fix required, then release the software. I can step up to do this over the next few days. I think Henning was concerned we'd need to rebuild the site and he's the only one that can do that. If I managed the release, I'd probably want to do Velocity 1.5rc1 first and then Velocity 1.5 two weeks later. Why is he the only one that can do the site? because Maven2 has issues and that's what the current site is being built with. i've tried to get it working on my machine, but no luck yet. (3) Henning remains release manager and we wait until March for the release. We could leave the VELOCITY_1.5_BRANCH up so that the release is ready to go. We can also direct users interested in 1.5 specific features to that svn branch. Right. Do the fixes in the branch, then make a tag/1.5rc1 build, vote and release as RC1. When Henning gets back, do 1.5 GA. Advantage is that people get to beat 1.5RC1 about for a month. geir I'm sure our European community is long abed, I'll look for comments from them in the morning. WILL On 1/30/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi, Knew I'd be unpopular the moment I hit send. Three quick notes. 1) don't think the changes are big. But I think the distro should be reviewed and fixed. A bad hyperlink on the main menu, in our first release in 3 years, looks sloppy and conveys an inaccurate impression of the quality of our product. 2) Unlike V-tools, we did not have a test build. Instead, the final package was created with the choice vote yes, or delay the release. I don't like it. 3) I'd be happy to vote +1 if we could call this Velocity 1.5rc1. But given the historic significance of this release, I urge us to release Velocity 1.5 in a professional distro without obvious errors. (no need to immediately issue Velocity 1.5.1). best, WILL On 1/30/07, Nathan Bubna [EMAIL PROTECTED] wrote: On 1/30/07, Will Glass-Husain [EMAIL PROTECTED] 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]. C'mon. Anakia's documentation is anything but hard to find. I'm all for getting things right, but not for holding back releases based on one missing doc. I'd rather you let Henning release 1.5 now and release 1.5.1 yourself next week. 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. We can't cower in fear of unknown bugs. Fix what you know and care about, then let's get this thing moving again. 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. How about two betas and a test build? That's what we've had. This release has had much time to prepare. More time won't kill us, but let's not pretend things are ever likely to be 100% set. Trust me, if i cared enough, i could start combing thru the docs of almost any major project you like and find dozens of errors. Same goes for most code. Final releases will never be perfect, but the shallow bugs theory won't work if we don't get *them* out there. Far fewer people bother with release candidates and betas. 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. And it's fixed, is
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
Just to clarify... 2) Unlike V-tools, we did not have a test build. Instead, the final package was created with the choice vote yes, or delay the release. no. we did have a test build and veltools did not. test build == unreleased build to be tested then voted upon What I meant is that there was no opportunity to offer fixes upon this build before voting. Due to the timing, Henning put that last touches on the build then called for a vote. Obviously, I'd much prefer to just have added the missing page to the Velocity 1.5 branch, but according to our recently clarified rules, I can't fix this and have this vote apply to that fix. We have to vote on a specific distribution. As a side question, is there a required voting period? It seems pretty obvious to me that we could do another vote and with everyone saying yes quickly, perhaps allowing Henning to still make this happen. Though I'd like to see an rc, I wouldn't insist on it. WILL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Release/Voting processes
ok, there seems to be some confusion about the different ways to prepare, label, and vote on releases. here's my understanding of the two most common options. 1) How we used to do it. We would put the quality/status of the release in the release name. These would typically go something like 1.5-beta1, 1.5-rc1, 1.5. If a second beta or RC was necessary, then those would end with a 2. The proper way to begin this release process is to build the distribution with the anticipated release name (say 1.5-beta1) and upload it to where dev@ folks can get it. This is what i would call the test build. Once this test build is available, then call for a simple +1 (release it), 0 (i'm ambivalent), -1 (don't release) vote. This is a perfectly valid process, though it has the disadvantage that the quality/status of the release cannot be changed even if our opinions of it have changed for better or worse. If 1.5-rc1 turned out to have no problems anyone found or cared about, then we would still have to rebuild a release named 1.5, upload the test build of it, and then vote to release it, even though the only needed change was in the name. The improper way to do this is to call for a vote before providing the build for people to test. Henning initially did this with 1.5, and i did it for both Veltools 1.3-beta1 and Veltools 1.3-rc1. That was the lazy, improper way and won't be done again. However, for Henning's second try at 1.5, he did provide a proper test build for us to download and try before voting. 2) How i'd like to see us to do it. We would not put the quality/status of the release in the release name. Instead, the release is only given a number (typically in X.Y.Z form, but there's no reason for that but convention), and the quality/status of the release is decided by vote and labeled on the website and not in the release itself. The proper way to begin this release process is to build the distribution with the current release number and upload it to where dev@ folks can get it. This is, again, the test build. Once the test build is available, the release manager calls for a vote on the quality of the build +1 (GA), +1 (Beta), or +1 (Alpha). I don't really see much point in have a +1 (RC) option, but some like it. Once the vote is over, the release may be made available with the quality determined clearly labeled on the download page and in all announcements. This means that we don't have to do a new release if an RC is found to be perfect. All we have to do is re-vote, change the website, and announce it (if we want). It also provides a clear means to demote releases in which serious problems are later found. This ease of changing status makes it easier to have more frequent releases, and helps to ensure that the work of doing a release is not voided by a -1 vote. Instead, the quality just gets lowered, but the release still happens and is available to those who want it. We've discussed switching to 2), but i'm not aware of a clear decision or consensus on that, so it feels like we're still talking about both, hoping that one or the other will work better for us here. I really want to move to 2), but i've seen on other projects that the switch takes some getting used to. It may be best if we stick to 1) until Velocity 1.5 and Veltools 1.3 are out. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
