RE: Future Release Suggestion
If noone else is doing this, I've got a day or two to give to this Since support for 3.2 is being dropped - shall I replace the 32 target with a 33 target when submitting the diff? chanoch - The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Although we routinely screen for viruses, recipients should check this e-mail and any attachment for viruses. We make no warranty as to absence of viruses in this e-mail or any attachments. -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED]] Sent: 16 October 2002 00:22 To: 'Struts Developers List' Subject: RE: Future Release Suggestion If you, or someone else with some time on their hands, are a Tomcat user, there is one thing that would be a big help. We have a series of unit tests that are run against different Tomcat versions. At this time, we have configurations for Tomcat 3.2, 4.0 and 4.1. However, we know that Struts does not work with Tomcat 3.2, and have decided to drop support for 3.2 in favour of 3.3. However, at this time we don't have a test configuration for 3.3. I started messing with this a while ago, and discovered that 3.3 is different enough from both 3.2 and 4.0 that blindly hacking at one of these didn't work. ;-) However, I'm not a Tomcat user, so not really familiar with what I needed to do to get it working. If someone is up for this, the place to look is build-tests.xml, in the root of the Struts source tree. There, you'll find targets such as 'test.tomcat.nn' where 'nn' is 32, 40 or 41. All we need is a 'test.tomcat.33' that works against Tomcat 3.3.1. ;-) Seriously, though, it would be great to get this working. -- Martin Cooper -Original Message- From: Daniel Honig [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 4:05 PM To: Struts Developers List Subject: RE: Future Release Suggestion Hello, With this in mind I'd like to announce that I've got some time on my hands. Probably too much. So I'd like to attempt to get out of lurker mode and start helping out the committers. Can someone give me some direction as to some bugs that might be good to look at. I'll probaby spend half a day getting up to speed on catctus and the test framework which is crucial for any patches I might suggest. But I'd love to have a few of the committers deputize me to go off and inspect some issues. I've been collaborating with a couple guys on a tag library for WML. They've had to do most of the work until now so part of my effort is going to be helping them validate it and get it ready for review by the larger community. -Daniel -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 6:50 PM To: Struts Developers List Subject: Re: Future Release Suggestion As Craig pointed out recently, we all really do this for our own use, and if someone else can use it too, then that's icing on the cake. Most of the Committers are highly enough placed in their own organizations that they can use the nightly build if they have to. So, the pressure to make incremental releases has not been so great. But a good portion of my income now comes from working with teams that are prohibited from using betas or a nightly build. So, to keep shoes on the kids, I'm going to need to work toward more incremental releases, so that my clients can use it (and so they can in turn use me ;0) But, yes, I think that down the road we will need to start looking for reasons to cut a release. If we have several releases a year, then there will be less pressure to slip in one more gotta have it, since the next release won't be so far away. Of course, at this point the die is cast, and we need to debug the features already promised. -Ted. 10/15/2002 6:35:28 PM, David Graham [EMAIL PROTECTED] wrote: I think the problem is that some very heavy hitters were added into 1.1. Validator, sub modules, map backed form attributes, tiles, RequestProcessor, Plugins, etc. are all new (AFAIK) to 1.1. This amount of change requires quite a while to accomplish. It may be beneficial in the future to address bug fixes and one big new item per release. This way, production releases are more frequent. What do the comitters think? David From: [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Struts 1.1 Release Date: Tue, 15 Oct 2002 23:25:40 +0100 I totally understand and agree
Re: RE: Future Release Suggestion
A good way to go would be to open a ticket in Bugzilla with the notes from this thread, and mention that you are working on an implementation there. 10/16/2002 6:27:16 AM, Chanoch [EMAIL PROTECTED] wrote: If noone else is doing this, I've got a day or two to give to this Since support for 3.2 is being dropped - shall I replace the 32 target with a 33 target when submitting the diff? chanoch - The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Although we routinely screen for viruses, recipients should check this e-mail and any attachment for viruses. We make no warranty as to absence of viruses in this e-mail or any attachments. -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED]] Sent: 16 October 2002 00:22 To: 'Struts Developers List' Subject: RE: Future Release Suggestion If you, or someone else with some time on their hands, are a Tomcat user, there is one thing that would be a big help. We have a series of unit tests that are run against different Tomcat versions. At this time, we have configurations for Tomcat 3.2, 4.0 and 4.1. However, we know that Struts does not work with Tomcat 3.2, and have decided to drop support for 3.2 in favour of 3.3. However, at this time we don't have a test configuration for 3.3. I started messing with this a while ago, and discovered that 3.3 is different enough from both 3.2 and 4.0 that blindly hacking at one of these didn't work. ;-) However, I'm not a Tomcat user, so not really familiar with what I needed to do to get it working. If someone is up for this, the place to look is build-tests.xml, in the root of the Struts source tree. There, you'll find targets such as 'test.tomcat.nn' where 'nn' is 32, 40 or 41. All we need is a 'test.tomcat.33' that works against Tomcat 3.3.1. ;-) Seriously, though, it would be great to get this working. -- Martin Cooper -Original Message- From: Daniel Honig [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 4:05 PM To: Struts Developers List Subject: RE: Future Release Suggestion Hello, With this in mind I'd like to announce that I've got some time on my hands. Probably too much. So I'd like to attempt to get out of lurker mode and start helping out the committers. Can someone give me some direction as to some bugs that might be good to look at. I'll probaby spend half a day getting up to speed on catctus and the test framework which is crucial for any patches I might suggest. But I'd love to have a few of the committers deputize me to go off and inspect some issues. I've been collaborating with a couple guys on a tag library for WML. They've had to do most of the work until now so part of my effort is going to be helping them validate it and get it ready for review by the larger community. -Daniel -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 6:50 PM To: Struts Developers List Subject: Re: Future Release Suggestion As Craig pointed out recently, we all really do this for our own use, and if someone else can use it too, then that's icing on the cake. Most of the Committers are highly enough placed in their own organizations that they can use the nightly build if they have to. So, the pressure to make incremental releases has not been so great. But a good portion of my income now comes from working with teams that are prohibited from using betas or a nightly build. So, to keep shoes on the kids, I'm going to need to work toward more incremental releases, so that my clients can use it (and so they can in turn use me ;0) But, yes, I think that down the road we will need to start looking for reasons to cut a release. If we have several releases a year, then there will be less pressure to slip in one more gotta have it, since the next release won't be so far away. Of course, at this point the die is cast, and we need to debug the features already promised. -Ted. 10/15/2002 6:35:28 PM, David Graham [EMAIL PROTECTED] wrote: I think the problem is that some very heavy hitters were added into 1.1. Validator, sub modules, map backed form attributes, tiles, RequestProcessor, Plugins, etc. are all new (AFAIK) to 1.1. This amount of change requires quite a while to accomplish. It may be beneficial in the future to address bug fixes and one big new item per release. This way, production releases are more frequent. What do the comitters think? David
Re: Future Release Suggestion
And should anyone have an itch to scratch. http://jakarta.apache.org/struts/helping.html Since this is a volunteer project, we are all our own customers. Many other products have people working on them as part of the paid jobs. ASFAIK, that's not happening with Struts right now. My sincere suggestion to the corporate teams that depend on Struts is that's it time to step up to the plate. If ~you~ need a release out the door, it's up to *you* to see that it happens. Craig tells a story of a time when he needed Tomcat out the door so his team could use it. His son (bless his soul) said Dad, you know Java, why don't you help. The rest, as they say, is history. http://jakarta.apache.org/site/getinvolved.html We've been putting more Comitters on the team, which should help put through the patches we already have, but we still need more developers submitting patches for other issues -- and especially *unit tests* to prove the issues are fixed. -Ted. 10/15/2002 7:53:44 PM, [EMAIL PROTECTED] wrote: To blatently steal words from my favorite book on development - The Cathedral and the Bazaar by Erik Raymond (http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/). In the section where he describes the rise of Linux and how Linus Torvolds help Linux achieve such wide adoption, he states his rule number 7 for open source: 7. Release early. Release often. And listen to your customers. For example, look at Tomcat release 4.0 v4.018-Sep-2001 v4.0.1 29-Apr-2002 v4.0.2 10-Feb-2002 v4.0.3 02-Mar-2002 v4.0.4 28-Mar-2002 v4.0.5 24-Sep-2002 v4.0.6 08-Oct-2002 (Some of the dates may be a bit off - I had to surf ViewCVS looking at old release notes) All these are stable releases. 7 releases in just over a year. I'd wager that accellerating the release process for Struts would accelerate its adoption by corporations - and provide a lot more clients to help put shoes on the kids. Plus the rest of us could use the cool new features as well. Ted Husted [EMAIL PROTECTED] on 10/15/2002 06:50:23 PM Please respond to Struts Developers List [EMAIL PROTECTED] To:Struts Developers List [EMAIL PROTECTED] cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) Subject:Re: Future Release Suggestion As Craig pointed out recently, we all really do this for our own use, and if someone else can use it too, then that's icing on the cake. Most of the Committers are highly enough placed in their own organizations that they can use the nightly build if they have to. So, the pressure to make incremental releases has not been so great. But a good portion of my income now comes from working with teams that are prohibited from using betas or a nightly build. So, to keep shoes on the kids, I'm going to need to work toward more incremental releases, so that my clients can use it (and so they can in turn use me ;0) But, yes, I think that down the road we will need to start looking for reasons to cut a release. If we have several releases a year, then there will be less pressure to slip in one more gotta have it, since the next release won't be so far away. Of course, at this point the die is cast, and we need to debug the features already promised. -Ted. 10/15/2002 6:35:28 PM, David Graham [EMAIL PROTECTED] wrote: I think the problem is that some very heavy hitters were added into 1.1. Validator, sub modules, map backed form attributes, tiles, RequestProcessor, Plugins, etc. are all new (AFAIK) to 1.1. This amount of change requires quite a while to accomplish. It may be beneficial in the future to address bug fixes and one big new item per release. This way, production releases are more frequent. What do the comitters think? David From: [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Struts 1.1 Release Date: Tue, 15 Oct 2002 23:25:40 +0100 I totally understand and agree with the release policy, but I think it's worth remembering that a lot of these questions are driven by the constraints of users' environments - e.g. in corporate environments like ours, there any many people like myself continually fighting to get great open source products like Struts into the organisation so that development teams can use them, and the latest versions of them. However, this has to be done within the processes and policies that apply to any third party software, commercial or otherwise. Specifically, in our case, I am the product owner of Struts here among other products from the Apache family of projects here and it is my responsibility to make the standard builds of Struts on our software distribution servers so that development can reference this for use by their applications, as must be done for all external software (it's an audit point). However, in order to do this, I must get the new version approved by a central department which is extremely difficult, if not impossible for software
Testing struts on 3.3.1 [WAS] RE: Future Release Suggestion
Well, its done (test org.apache.struts.action.TestDynaActionForm failed btw.) Slight problem that this email account is currently not letting me receive emails so I don't know where things are at. I will work on getting the files to you tomorrow. chanoch -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Future Release Suggestion
-Original Message- From: Chanoch [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 3:27 AM To: 'Struts Developers List' Subject: RE: Future Release Suggestion If noone else is doing this, I've got a day or two to give to this Awesome! Thanks! Since support for 3.2 is being dropped - shall I replace the 32 target with a 33 target when submitting the diff? You might as well leave the 3.2 tests there for now, just in case someone is sufficiently determined to figure out a way to get Struts 1.1 working with Tomcat 3.2.4. Both Craig and I looked at this before, and we decided it was probably a Tomcat class loader bug. But someone else might figure out a way to work around it. -- Martin Cooper chanoch - The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Although we routinely screen for viruses, recipients should check this e-mail and any attachment for viruses. We make no warranty as to absence of viruses in this e-mail or any attachments. -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED]] Sent: 16 October 2002 00:22 To: 'Struts Developers List' Subject: RE: Future Release Suggestion If you, or someone else with some time on their hands, are a Tomcat user, there is one thing that would be a big help. We have a series of unit tests that are run against different Tomcat versions. At this time, we have configurations for Tomcat 3.2, 4.0 and 4.1. However, we know that Struts does not work with Tomcat 3.2, and have decided to drop support for 3.2 in favour of 3.3. However, at this time we don't have a test configuration for 3.3. I started messing with this a while ago, and discovered that 3.3 is different enough from both 3.2 and 4.0 that blindly hacking at one of these didn't work. ;-) However, I'm not a Tomcat user, so not really familiar with what I needed to do to get it working. If someone is up for this, the place to look is build-tests.xml, in the root of the Struts source tree. There, you'll find targets such as 'test.tomcat.nn' where 'nn' is 32, 40 or 41. All we need is a 'test.tomcat.33' that works against Tomcat 3.3.1. ;-) Seriously, though, it would be great to get this working. -- Martin Cooper -Original Message- From: Daniel Honig [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 4:05 PM To: Struts Developers List Subject: RE: Future Release Suggestion Hello, With this in mind I'd like to announce that I've got some time on my hands. Probably too much. So I'd like to attempt to get out of lurker mode and start helping out the committers. Can someone give me some direction as to some bugs that might be good to look at. I'll probaby spend half a day getting up to speed on catctus and the test framework which is crucial for any patches I might suggest. But I'd love to have a few of the committers deputize me to go off and inspect some issues. I've been collaborating with a couple guys on a tag library for WML. They've had to do most of the work until now so part of my effort is going to be helping them validate it and get it ready for review by the larger community. -Daniel -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 6:50 PM To: Struts Developers List Subject: Re: Future Release Suggestion As Craig pointed out recently, we all really do this for our own use, and if someone else can use it too, then that's icing on the cake. Most of the Committers are highly enough placed in their own organizations that they can use the nightly build if they have to. So, the pressure to make incremental releases has not been so great. But a good portion of my income now comes from working with teams that are prohibited from using betas or a nightly build. So, to keep shoes on the kids, I'm going to need to work toward more incremental releases, so that my clients can use it (and so they can in turn use me ;0) But, yes, I think that down the road we will need to start looking for reasons to cut a release. If we have several releases a year, then there will be less pressure to slip in one more gotta have it, since the next release won't be so far away. Of course, at this point the die is cast, and we need to debug the features already promised. -Ted. 10/15/2002 6:35:28 PM, David
Future Release Suggestion
I think the problem is that some very heavy hitters were added into 1.1. Validator, sub modules, map backed form attributes, tiles, RequestProcessor, Plugins, etc. are all new (AFAIK) to 1.1. This amount of change requires quite a while to accomplish. It may be beneficial in the future to address bug fixes and one big new item per release. This way, production releases are more frequent. What do the comitters think? David From: [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Struts 1.1 Release Date: Tue, 15 Oct 2002 23:25:40 +0100 I totally understand and agree with the release policy, but I think it's worth remembering that a lot of these questions are driven by the constraints of users' environments - e.g. in corporate environments like ours, there any many people like myself continually fighting to get great open source products like Struts into the organisation so that development teams can use them, and the latest versions of them. However, this has to be done within the processes and policies that apply to any third party software, commercial or otherwise. Specifically, in our case, I am the product owner of Struts here among other products from the Apache family of projects here and it is my responsibility to make the standard builds of Struts on our software distribution servers so that development can reference this for use by their applications, as must be done for all external software (it's an audit point). However, in order to do this, I must get the new version approved by a central department which is extremely difficult, if not impossible for software that is tagged as beta regardless of the quality. (Yes, you can imagine how commercial software vendors deal with this in their versioning policy... :-( ) Therefore, all our applications are currently stuck on v1.0.2 rather than the latest and greatest 1.1 regardless of how stable it may be in practice. I know that we are not alone in this kind of approach, and that this kind of situation and red tape is the reality in big organisations... Working in one of our architecture teams, I advise application development teams in our area when it comes to working out and implementing their roadmaps, and part of this requires the recommendation of technologies on the basis of an understanding of when certain products such as Struts can be made available for their use - this applies equally to any kind of software. So I would be interested in hearing any suggestions about how we could resolve the need for us to have a better understanding of how close we are to a final release of any given version, e.g. clearly listing the issues that are preventing a release being deemed as 1.1 quality on the website? Would it be possible to change the versioning policy so that more non-beta dot releases are made possible, since many components are known to have no issues? These are just some ideas - they may well not be workable but I would like to know what could be done, since it is very frustrating for me and others like me to play with great beta products and rave about them to colleagues, but not be able to make them available for use by their applications - this ultimately results in a lack of interest and apathy towards such products, which is a great shame given their quality. Hope something useful can come out of this! Best regards, Kosh -Original Message- From: Chappell, Simon P [mailto:[EMAIL PROTECTED]] Sent: 15 October 2002 22:58 To: Struts Users Mailing List Subject: RE: Struts 1.1 Release Were you subscribed to the mailing list earlier today when this was discussed? Struts 1.1 will be released when it's released. Period. No variation from that. That said, even the beta versions of Struts far exceed other software in terms of usefulness and reliability, so don't worry about formal release dates and just start using the thing. Simon - Simon P. Chappell [EMAIL PROTECTED] Java Programming Specialist www.landsend.com Lands' End, Inc. (608) 935-4526 -Original Message- From: Bachan Sadanandan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 4:54 PM To: Struts Users Mailing List Subject: Struts 1.1 Release Hi all, Any idea when Struts 1.1 would be ready for Production .??? Thanks ! Bachan -- To unsubscribe, e-mail: mailto:struts-user-[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not
Re: Future Release Suggestion
As Craig pointed out recently, we all really do this for our own use, and if someone else can use it too, then that's icing on the cake. Most of the Committers are highly enough placed in their own organizations that they can use the nightly build if they have to. So, the pressure to make incremental releases has not been so great. But a good portion of my income now comes from working with teams that are prohibited from using betas or a nightly build. So, to keep shoes on the kids, I'm going to need to work toward more incremental releases, so that my clients can use it (and so they can in turn use me ;0) But, yes, I think that down the road we will need to start looking for reasons to cut a release. If we have several releases a year, then there will be less pressure to slip in one more gotta have it, since the next release won't be so far away. Of course, at this point the die is cast, and we need to debug the features already promised. -Ted. 10/15/2002 6:35:28 PM, David Graham [EMAIL PROTECTED] wrote: I think the problem is that some very heavy hitters were added into 1.1. Validator, sub modules, map backed form attributes, tiles, RequestProcessor, Plugins, etc. are all new (AFAIK) to 1.1. This amount of change requires quite a while to accomplish. It may be beneficial in the future to address bug fixes and one big new item per release. This way, production releases are more frequent. What do the comitters think? David From: [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Struts 1.1 Release Date: Tue, 15 Oct 2002 23:25:40 +0100 I totally understand and agree with the release policy, but I think it's worth remembering that a lot of these questions are driven by the constraints of users' environments - e.g. in corporate environments like ours, there any many people like myself continually fighting to get great open source products like Struts into the organisation so that development teams can use them, and the latest versions of them. However, this has to be done within the processes and policies that apply to any third party software, commercial or otherwise. Specifically, in our case, I am the product owner of Struts here among other products from the Apache family of projects here and it is my responsibility to make the standard builds of Struts on our software distribution servers so that development can reference this for use by their applications, as must be done for all external software (it's an audit point). However, in order to do this, I must get the new version approved by a central department which is extremely difficult, if not impossible for software that is tagged as beta regardless of the quality. (Yes, you can imagine how commercial software vendors deal with this in their versioning policy... :-( ) Therefore, all our applications are currently stuck on v1.0.2 rather than the latest and greatest 1.1 regardless of how stable it may be in practice. I know that we are not alone in this kind of approach, and that this kind of situation and red tape is the reality in big organisations... Working in one of our architecture teams, I advise application development teams in our area when it comes to working out and implementing their roadmaps, and part of this requires the recommendation of technologies on the basis of an understanding of when certain products such as Struts can be made available for their use - this applies equally to any kind of software. So I would be interested in hearing any suggestions about how we could resolve the need for us to have a better understanding of how close we are to a final release of any given version, e.g. clearly listing the issues that are preventing a release being deemed as 1.1 quality on the website? Would it be possible to change the versioning policy so that more non-beta dot releases are made possible, since many components are known to have no issues? These are just some ideas - they may well not be workable but I would like to know what could be done, since it is very frustrating for me and others like me to play with great beta products and rave about them to colleagues, but not be able to make them available for use by their applications - this ultimately results in a lack of interest and apathy towards such products, which is a great shame given their quality. Hope something useful can come out of this! Best regards, Kosh -Original Message- From: Chappell, Simon P [mailto:[EMAIL PROTECTED]] Sent: 15 October 2002 22:58 To: Struts Users Mailing List Subject: RE: Struts 1.1 Release Were you subscribed to the mailing list earlier today when this was discussed? Struts 1.1 will be released when it's released. Period. No variation from that. That said, even the beta versions of Struts far exceed other software in terms of usefulness and reliability, so don't worry about formal
RE: Future Release Suggestion
If you, or someone else with some time on their hands, are a Tomcat user, there is one thing that would be a big help. We have a series of unit tests that are run against different Tomcat versions. At this time, we have configurations for Tomcat 3.2, 4.0 and 4.1. However, we know that Struts does not work with Tomcat 3.2, and have decided to drop support for 3.2 in favour of 3.3. However, at this time we don't have a test configuration for 3.3. I started messing with this a while ago, and discovered that 3.3 is different enough from both 3.2 and 4.0 that blindly hacking at one of these didn't work. ;-) However, I'm not a Tomcat user, so not really familiar with what I needed to do to get it working. If someone is up for this, the place to look is build-tests.xml, in the root of the Struts source tree. There, you'll find targets such as 'test.tomcat.nn' where 'nn' is 32, 40 or 41. All we need is a 'test.tomcat.33' that works against Tomcat 3.3.1. ;-) Seriously, though, it would be great to get this working. -- Martin Cooper -Original Message- From: Daniel Honig [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 4:05 PM To: Struts Developers List Subject: RE: Future Release Suggestion Hello, With this in mind I'd like to announce that I've got some time on my hands. Probably too much. So I'd like to attempt to get out of lurker mode and start helping out the committers. Can someone give me some direction as to some bugs that might be good to look at. I'll probaby spend half a day getting up to speed on catctus and the test framework which is crucial for any patches I might suggest. But I'd love to have a few of the committers deputize me to go off and inspect some issues. I've been collaborating with a couple guys on a tag library for WML. They've had to do most of the work until now so part of my effort is going to be helping them validate it and get it ready for review by the larger community. -Daniel -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 6:50 PM To: Struts Developers List Subject: Re: Future Release Suggestion As Craig pointed out recently, we all really do this for our own use, and if someone else can use it too, then that's icing on the cake. Most of the Committers are highly enough placed in their own organizations that they can use the nightly build if they have to. So, the pressure to make incremental releases has not been so great. But a good portion of my income now comes from working with teams that are prohibited from using betas or a nightly build. So, to keep shoes on the kids, I'm going to need to work toward more incremental releases, so that my clients can use it (and so they can in turn use me ;0) But, yes, I think that down the road we will need to start looking for reasons to cut a release. If we have several releases a year, then there will be less pressure to slip in one more gotta have it, since the next release won't be so far away. Of course, at this point the die is cast, and we need to debug the features already promised. -Ted. 10/15/2002 6:35:28 PM, David Graham [EMAIL PROTECTED] wrote: I think the problem is that some very heavy hitters were added into 1.1. Validator, sub modules, map backed form attributes, tiles, RequestProcessor, Plugins, etc. are all new (AFAIK) to 1.1. This amount of change requires quite a while to accomplish. It may be beneficial in the future to address bug fixes and one big new item per release. This way, production releases are more frequent. What do the comitters think? David From: [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Struts 1.1 Release Date: Tue, 15 Oct 2002 23:25:40 +0100 I totally understand and agree with the release policy, but I think it's worth remembering that a lot of these questions are driven by the constraints of users' environments - e.g. in corporate environments like ours, there any many people like myself continually fighting to get great open source products like Struts into the organisation so that development teams can use them, and the latest versions of them. However, this has to be done within the processes and policies that apply to any third party software, commercial or otherwise. Specifically, in our case, I am the product owner of Struts here among other products from the Apache family of projects here and it is my responsibility to make the standard builds of Struts on our software distribution servers so that development can reference this for use by their applications, as must be done for all external software (it's an audit point). However, in order to do this, I must get the new version approved by a central department which is extremely difficult, if not impossible
Re: Future Release Suggestion
To blatently steal words from my favorite book on development - The Cathedral and the Bazaar by Erik Raymond (http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/). In the section where he describes the rise of Linux and how Linus Torvolds help Linux achieve such wide adoption, he states his rule number 7 for open source: 7. Release early. Release often. And listen to your customers. For example, look at Tomcat release 4.0 v4.018-Sep-2001 v4.0.1 29-Apr-2002 v4.0.2 10-Feb-2002 v4.0.3 02-Mar-2002 v4.0.4 28-Mar-2002 v4.0.5 24-Sep-2002 v4.0.6 08-Oct-2002 (Some of the dates may be a bit off - I had to surf ViewCVS looking at old release notes) All these are stable releases. 7 releases in just over a year. I'd wager that accellerating the release process for Struts would accelerate its adoption by corporations - and provide a lot more clients to help put shoes on the kids. Plus the rest of us could use the cool new features as well. Ted Husted [EMAIL PROTECTED] on 10/15/2002 06:50:23 PM Please respond to Struts Developers List [EMAIL PROTECTED] To:Struts Developers List [EMAIL PROTECTED] cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) Subject:Re: Future Release Suggestion As Craig pointed out recently, we all really do this for our own use, and if someone else can use it too, then that's icing on the cake. Most of the Committers are highly enough placed in their own organizations that they can use the nightly build if they have to. So, the pressure to make incremental releases has not been so great. But a good portion of my income now comes from working with teams that are prohibited from using betas or a nightly build. So, to keep shoes on the kids, I'm going to need to work toward more incremental releases, so that my clients can use it (and so they can in turn use me ;0) But, yes, I think that down the road we will need to start looking for reasons to cut a release. If we have several releases a year, then there will be less pressure to slip in one more gotta have it, since the next release won't be so far away. Of course, at this point the die is cast, and we need to debug the features already promised. -Ted. 10/15/2002 6:35:28 PM, David Graham [EMAIL PROTECTED] wrote: I think the problem is that some very heavy hitters were added into 1.1. Validator, sub modules, map backed form attributes, tiles, RequestProcessor, Plugins, etc. are all new (AFAIK) to 1.1. This amount of change requires quite a while to accomplish. It may be beneficial in the future to address bug fixes and one big new item per release. This way, production releases are more frequent. What do the comitters think? David From: [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Struts 1.1 Release Date: Tue, 15 Oct 2002 23:25:40 +0100 I totally understand and agree with the release policy, but I think it's worth remembering that a lot of these questions are driven by the constraints of users' environments - e.g. in corporate environments like ours, there any many people like myself continually fighting to get great open source products like Struts into the organisation so that development teams can use them, and the latest versions of them. However, this has to be done within the processes and policies that apply to any third party software, commercial or otherwise. Specifically, in our case, I am the product owner of Struts here among other products from the Apache family of projects here and it is my responsibility to make the standard builds of Struts on our software distribution servers so that development can reference this for use by their applications, as must be done for all external software (it's an audit point). However, in order to do this, I must get the new version approved by a central department which is extremely difficult, if not impossible for software that is tagged as beta regardless of the quality. (Yes, you can imagine how commercial software vendors deal with this in their versioning policy... :-( ) Therefore, all our applications are currently stuck on v1.0.2 rather than the latest and greatest 1.1 regardless of how stable it may be in practice. I know that we are not alone in this kind of approach, and that this kind of situation and red tape is the reality in big organisations... Working in one of our architecture teams, I advise application development teams in our area when it comes to working out and implementing their roadmaps, and part of this requires the recommendation of technologies on the basis of an understanding of when certain products such as Struts can be made available for their use - this applies equally to any kind of software. So I would be interested in hearing any suggestions about how we could resolve the need for us to have a better understanding of how close we are to a final release of any given version, e.g
