Re: CVS - SVN / Roadmap
I should be able to bring the Roadmap up to date later today (Friday), so you will be able to roll it over the weekend. -Ted. On Thu, 14 Oct 2004 15:40:56 -0700, Don Brown wrote: All that should remain is updating the roadmap, which I'll leave to folks more involved in the roadmap discussions. If there is anything else, let me know and I'll do it. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS - SVN / Roadmap
+1 Let's stick to the roadmap we laid out in July. http://struts.apache.org/roadmap.html I'll update the site to reflect the CVS/SVN changes this weekend and bring the roadmap page up to date. If James is up for rolling a 1.2.5 release, that's fine with me. Either way, it may be time to call 1.2.x a branch and dub the head 1.3.x, and bring down that-there Struts Chain gizmo. :) And if Don wants to start setting up struts-flow and struts-scripting along the same lines as struts-faces, I'll buy him a Guiness (or three) at ApacheCon :) -Ted. On Wed, 13 Oct 2004 13:45:58 -0700, Craig McClanahan wrote: On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein [EMAIL PROTECTED] wrote: Forgive my possible ignorance, but what is the policy on new releases? I've understood that we can release whenever we want, that version numbers are cheap and that you vote whether to make a release alpha/beta/GA. But, what goes into a release? Does new features/enhancements go into a 1.2.x release, or is it strictly bug fixes? What we've talked about before is along these lines: Within the 1.2.x series, it's fine to fix bugs and add new stuff, but not fine to make any backwards-incompatible changes. For a 1.3.x series, we could be more liberal about adding new stuff, and possibly have some deprecations in 1.2.x that get removed -- but it shoujld in general be based on similar enough architectural principles that there be a clear upgrade path. The challenge, of course, is when do you make that split for the evolutionary path? I'd say that something as fundamental as using Struts Chain instead of the monolithic RequestProcessor, and the other changes we could make as a result of having that, would be good grounds for a 1.3.x series. If that were to start in the short term, then thinking of 1.2.x as being in maintenance mode seems likely (although if there's willingness to port features back and forth, it need not go that way immediately ... for example, Tomcat 4.1.x continued to develop for a little while at the beginning of 5.0.x, including some features ported back and forth, but this pretty much stopped as soon as there was a solid 5.0.x release for people to use). For a 2.x chain, we could have the freedom to be somewhat more aggressive at rearchitecting (if we'd known then what we know now, what would Struts have looked like?), and could in theory have a series of alpha releases in parallel with stable releases on 1.2 or 1.3. As others have pointed out, how much simultanaeity there is, and how often releases happen, is more based on the directed energy of the committers (and what they want to work on), and less on whether there are parallel development efforts going on. The reason I ask is because I would love releases much, much more often, but as have been pointed out, incompatibilities/quirks between minor versions could be a disaster. Historically, I'd say our 1.0 - 1.1 transition was, in terms of interoperability and upgrade, a bit on the edge of what most users liked, while the 1.1 - 1.2 transition was much easier to do. We haven't actually gotten around to many x.y.z releases on 1.0 or 1.1, so having them happen at all in 1.2 should be a refreshing change :-). But I agree with you that compatibility is especially important within an x.y release cycle. \Anders Craig - 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: CVS - SVN / Roadmap
Ted Husted wrote: +1 Let's stick to the roadmap we laid out in July. http://struts.apache.org/roadmap.html I'll update the site to reflect the CVS/SVN changes this weekend and bring the roadmap page up to date. If James is up for rolling a 1.2.5 release, that's fine with me. Either way, it may be time to call 1.2.x a branch and dub the head 1.3.x, and bring down that-there Struts Chain gizmo. :) +1 I vote we (or perhaps I specifically) integrate struts-chain this weekend. It is stable, and I've been using it in production for some time without problems. Course that also means we (again, perhaps I specifically) should release commons-chain 1.0. Ted, there are a few Guinnesses in it if you help me with the documentation :) And if Don wants to start setting up struts-flow and struts-scripting along the same lines as struts-faces, I'll buy him a Guiness (or three) at ApacheCon :) Ah, Guinness - the ultimate currency. You got yourself a deal. Don -Ted. On Wed, 13 Oct 2004 13:45:58 -0700, Craig McClanahan wrote: On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein [EMAIL PROTECTED] wrote: Forgive my possible ignorance, but what is the policy on new releases? I've understood that we can release whenever we want, that version numbers are cheap and that you vote whether to make a release alpha/beta/GA. But, what goes into a release? Does new features/enhancements go into a 1.2.x release, or is it strictly bug fixes? What we've talked about before is along these lines: Within the 1.2.x series, it's fine to fix bugs and add new stuff, but not fine to make any backwards-incompatible changes. For a 1.3.x series, we could be more liberal about adding new stuff, and possibly have some deprecations in 1.2.x that get removed -- but it shoujld in general be based on similar enough architectural principles that there be a clear upgrade path. The challenge, of course, is when do you make that split for the evolutionary path? I'd say that something as fundamental as using Struts Chain instead of the monolithic RequestProcessor, and the other changes we could make as a result of having that, would be good grounds for a 1.3.x series. If that were to start in the short term, then thinking of 1.2.x as being in maintenance mode seems likely (although if there's willingness to port features back and forth, it need not go that way immediately ... for example, Tomcat 4.1.x continued to develop for a little while at the beginning of 5.0.x, including some features ported back and forth, but this pretty much stopped as soon as there was a solid 5.0.x release for people to use). For a 2.x chain, we could have the freedom to be somewhat more aggressive at rearchitecting (if we'd known then what we know now, what would Struts have looked like?), and could in theory have a series of alpha releases in parallel with stable releases on 1.2 or 1.3. As others have pointed out, how much simultanaeity there is, and how often releases happen, is more based on the directed energy of the committers (and what they want to work on), and less on whether there are parallel development efforts going on. The reason I ask is because I would love releases much, much more often, but as have been pointed out, incompatibilities/quirks between minor versions could be a disaster. Historically, I'd say our 1.0 - 1.1 transition was, in terms of interoperability and upgrade, a bit on the edge of what most users liked, while the 1.1 - 1.2 transition was much easier to do. We haven't actually gotten around to many x.y.z releases on 1.0 or 1.1, so having them happen at all in 1.2 should be a refreshing change :-). But I agree with you that compatibility is especially important within an x.y release cycle. \Anders Craig - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS - SVN / Roadmap
Ted, I will roll a release as soon as you say 'go'. If you and/or Martin (or anyone else that has time and patience to deal with me) could help with questions wrt label/branch/etc. -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Don Brown [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, October 14, 2004 11:30 AM Subject: Re: CVS - SVN / Roadmap Ted Husted wrote: +1 Let's stick to the roadmap we laid out in July. http://struts.apache.org/roadmap.html I'll update the site to reflect the CVS/SVN changes this weekend and bring the roadmap page up to date. If James is up for rolling a 1.2.5 release, that's fine with me. Either way, it may be time to call 1.2.x a branch and dub the head 1.3.x, and bring down that-there Struts Chain gizmo. :) +1 I vote we (or perhaps I specifically) integrate struts-chain this weekend. It is stable, and I've been using it in production for some time without problems. Course that also means we (again, perhaps I specifically) should release commons-chain 1.0. Ted, there are a few Guinnesses in it if you help me with the documentation :) And if Don wants to start setting up struts-flow and struts-scripting along the same lines as struts-faces, I'll buy him a Guiness (or three) at ApacheCon :) Ah, Guinness - the ultimate currency. You got yourself a deal. Don -Ted. On Wed, 13 Oct 2004 13:45:58 -0700, Craig McClanahan wrote: On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein [EMAIL PROTECTED] wrote: Forgive my possible ignorance, but what is the policy on new releases? I've understood that we can release whenever we want, that version numbers are cheap and that you vote whether to make a release alpha/beta/GA. But, what goes into a release? Does new features/enhancements go into a 1.2.x release, or is it strictly bug fixes? What we've talked about before is along these lines: Within the 1.2.x series, it's fine to fix bugs and add new stuff, but not fine to make any backwards-incompatible changes. For a 1.3.x series, we could be more liberal about adding new stuff, and possibly have some deprecations in 1.2.x that get removed -- but it shoujld in general be based on similar enough architectural principles that there be a clear upgrade path. The challenge, of course, is when do you make that split for the evolutionary path? I'd say that something as fundamental as using Struts Chain instead of the monolithic RequestProcessor, and the other changes we could make as a result of having that, would be good grounds for a 1.3.x series. If that were to start in the short term, then thinking of 1.2.x as being in maintenance mode seems likely (although if there's willingness to port features back and forth, it need not go that way immediately ... for example, Tomcat 4.1.x continued to develop for a little while at the beginning of 5.0.x, including some features ported back and forth, but this pretty much stopped as soon as there was a solid 5.0.x release for people to use). For a 2.x chain, we could have the freedom to be somewhat more aggressive at rearchitecting (if we'd known then what we know now, what would Struts have looked like?), and could in theory have a series of alpha releases in parallel with stable releases on 1.2 or 1.3. As others have pointed out, how much simultanaeity there is, and how often releases happen, is more based on the directed energy of the committers (and what they want to work on), and less on whether there are parallel development efforts going on. The reason I ask is because I would love releases much, much more often, but as have been pointed out, incompatibilities/quirks between minor versions could be a disaster. Historically, I'd say our 1.0 - 1.1 transition was, in terms of interoperability and upgrade, a bit on the edge of what most users liked, while the 1.1 - 1.2 transition was much easier to do. We haven't actually gotten around to many x.y.z releases on 1.0 or 1.1, so having them happen at all in 1.2 should be a refreshing change :-). But I agree with you that compatibility is especially important within an x.y release cycle. \Anders Craig - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: CVS - SVN / Roadmap
On Thu, 14 Oct 2004 12:50:49 -0400, James Mitchell [EMAIL PROTECTED] wrote: Ted, I will roll a release as soon as you say 'go'. If you and/or Martin (or anyone else that has time and patience to deal with me) could help with questions wrt label/branch/etc. I should be around this weekend. You know where to find me on IM. ;-) -- Martin Cooper -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Don Brown [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, October 14, 2004 11:30 AM Subject: Re: CVS - SVN / Roadmap Ted Husted wrote: +1 Let's stick to the roadmap we laid out in July. http://struts.apache.org/roadmap.html I'll update the site to reflect the CVS/SVN changes this weekend and bring the roadmap page up to date. If James is up for rolling a 1.2.5 release, that's fine with me. Either way, it may be time to call 1.2.x a branch and dub the head 1.3.x, and bring down that-there Struts Chain gizmo. :) +1 I vote we (or perhaps I specifically) integrate struts-chain this weekend. It is stable, and I've been using it in production for some time without problems. Course that also means we (again, perhaps I specifically) should release commons-chain 1.0. Ted, there are a few Guinnesses in it if you help me with the documentation :) And if Don wants to start setting up struts-flow and struts-scripting along the same lines as struts-faces, I'll buy him a Guiness (or three) at ApacheCon :) Ah, Guinness - the ultimate currency. You got yourself a deal. Don -Ted. On Wed, 13 Oct 2004 13:45:58 -0700, Craig McClanahan wrote: On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein [EMAIL PROTECTED] wrote: Forgive my possible ignorance, but what is the policy on new releases? I've understood that we can release whenever we want, that version numbers are cheap and that you vote whether to make a release alpha/beta/GA. But, what goes into a release? Does new features/enhancements go into a 1.2.x release, or is it strictly bug fixes? What we've talked about before is along these lines: Within the 1.2.x series, it's fine to fix bugs and add new stuff, but not fine to make any backwards-incompatible changes. For a 1.3.x series, we could be more liberal about adding new stuff, and possibly have some deprecations in 1.2.x that get removed -- but it shoujld in general be based on similar enough architectural principles that there be a clear upgrade path. The challenge, of course, is when do you make that split for the evolutionary path? I'd say that something as fundamental as using Struts Chain instead of the monolithic RequestProcessor, and the other changes we could make as a result of having that, would be good grounds for a 1.3.x series. If that were to start in the short term, then thinking of 1.2.x as being in maintenance mode seems likely (although if there's willingness to port features back and forth, it need not go that way immediately ... for example, Tomcat 4.1.x continued to develop for a little while at the beginning of 5.0.x, including some features ported back and forth, but this pretty much stopped as soon as there was a solid 5.0.x release for people to use). For a 2.x chain, we could have the freedom to be somewhat more aggressive at rearchitecting (if we'd known then what we know now, what would Struts have looked like?), and could in theory have a series of alpha releases in parallel with stable releases on 1.2 or 1.3. As others have pointed out, how much simultanaeity there is, and how often releases happen, is more based on the directed energy of the committers (and what they want to work on), and less on whether there are parallel development efforts going on. The reason I ask is because I would love releases much, much more often, but as have been pointed out, incompatibilities/quirks between minor versions could be a disaster. Historically, I'd say our 1.0 - 1.1 transition was, in terms of interoperability and upgrade, a bit on the edge of what most users liked, while the 1.1 - 1.2 transition was much easier to do. We haven't actually gotten around to many x.y.z releases on 1.0 or 1.1, so having them happen at all in 1.2 should be a refreshing change :-). But I agree with you that compatibility is especially important within an x.y release cycle. \Anders Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED
Re: CVS - SVN / Roadmap
On Thu, 14 Oct 2004 08:30:38 -0700, Don Brown [EMAIL PROTECTED] wrote: Ted Husted wrote: +1 Let's stick to the roadmap we laid out in July. http://struts.apache.org/roadmap.html I'll update the site to reflect the CVS/SVN changes this weekend and bring the roadmap page up to date. If James is up for rolling a 1.2.5 release, that's fine with me. Either way, it may be time to call 1.2.x a branch and dub the head 1.3.x, and bring down that-there Struts Chain gizmo. :) +1 I vote we (or perhaps I specifically) integrate struts-chain this weekend. It is stable, and I've been using it in production for some time without problems. Course that also means we (again, perhaps I specifically) should release commons-chain 1.0. Ted, there are a few Guinnesses in it if you help me with the documentation :) How about we roll 1.2.5 first, to capture the latest stuff in a 1.2.x build, then create a 1.2.x branch at that tag, and then roll in the chain stuff as the first step on the 1.3.x ladder? -- Martin Cooper And if Don wants to start setting up struts-flow and struts-scripting along the same lines as struts-faces, I'll buy him a Guiness (or three) at ApacheCon :) Ah, Guinness - the ultimate currency. You got yourself a deal. Don -Ted. On Wed, 13 Oct 2004 13:45:58 -0700, Craig McClanahan wrote: On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein [EMAIL PROTECTED] wrote: Forgive my possible ignorance, but what is the policy on new releases? I've understood that we can release whenever we want, that version numbers are cheap and that you vote whether to make a release alpha/beta/GA. But, what goes into a release? Does new features/enhancements go into a 1.2.x release, or is it strictly bug fixes? What we've talked about before is along these lines: Within the 1.2.x series, it's fine to fix bugs and add new stuff, but not fine to make any backwards-incompatible changes. For a 1.3.x series, we could be more liberal about adding new stuff, and possibly have some deprecations in 1.2.x that get removed -- but it shoujld in general be based on similar enough architectural principles that there be a clear upgrade path. The challenge, of course, is when do you make that split for the evolutionary path? I'd say that something as fundamental as using Struts Chain instead of the monolithic RequestProcessor, and the other changes we could make as a result of having that, would be good grounds for a 1.3.x series. If that were to start in the short term, then thinking of 1.2.x as being in maintenance mode seems likely (although if there's willingness to port features back and forth, it need not go that way immediately ... for example, Tomcat 4.1.x continued to develop for a little while at the beginning of 5.0.x, including some features ported back and forth, but this pretty much stopped as soon as there was a solid 5.0.x release for people to use). For a 2.x chain, we could have the freedom to be somewhat more aggressive at rearchitecting (if we'd known then what we know now, what would Struts have looked like?), and could in theory have a series of alpha releases in parallel with stable releases on 1.2 or 1.3. As others have pointed out, how much simultanaeity there is, and how often releases happen, is more based on the directed energy of the committers (and what they want to work on), and less on whether there are parallel development efforts going on. The reason I ask is because I would love releases much, much more often, but as have been pointed out, incompatibilities/quirks between minor versions could be a disaster. Historically, I'd say our 1.0 - 1.1 transition was, in terms of interoperability and upgrade, a bit on the edge of what most users liked, while the 1.1 - 1.2 transition was much easier to do. We haven't actually gotten around to many x.y.z releases on 1.0 or 1.1, so having them happen at all in 1.2 should be a refreshing change :-). But I agree with you that compatibility is especially important within an x.y release cycle. \Anders Craig - 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] - 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: CVS - SVN / Roadmap
Are we not waiting for Ted's update? I haven't seen any commits come across and I assumed he would do it this weekendis this still true Ted? -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Don Brown [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, October 14, 2004 1:49 PM Subject: Re: CVS - SVN / Roadmap Deal. Roll it James :) I'll integrate struts-chain and bring over struts-flow and struts-bsf as soon James cuts the release and creates the 1.2.x branch. Don Martin Cooper wrote: On Thu, 14 Oct 2004 08:30:38 -0700, Don Brown [EMAIL PROTECTED] wrote: Ted Husted wrote: +1 Let's stick to the roadmap we laid out in July. http://struts.apache.org/roadmap.html I'll update the site to reflect the CVS/SVN changes this weekend and bring the roadmap page up to date. If James is up for rolling a 1.2.5 release, that's fine with me. Either way, it may be time to call 1.2.x a branch and dub the head 1.3.x, and bring down that-there Struts Chain gizmo. :) +1 I vote we (or perhaps I specifically) integrate struts-chain this weekend. It is stable, and I've been using it in production for some time without problems. Course that also means we (again, perhaps I specifically) should release commons-chain 1.0. Ted, there are a few Guinnesses in it if you help me with the documentation :) How about we roll 1.2.5 first, to capture the latest stuff in a 1.2.x build, then create a 1.2.x branch at that tag, and then roll in the chain stuff as the first step on the 1.3.x ladder? -- Martin Cooper And if Don wants to start setting up struts-flow and struts-scripting along the same lines as struts-faces, I'll buy him a Guiness (or three) at ApacheCon :) Ah, Guinness - the ultimate currency. You got yourself a deal. Don -Ted. On Wed, 13 Oct 2004 13:45:58 -0700, Craig McClanahan wrote: On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein [EMAIL PROTECTED] wrote: Forgive my possible ignorance, but what is the policy on new releases? I've understood that we can release whenever we want, that version numbers are cheap and that you vote whether to make a release alpha/beta/GA. But, what goes into a release? Does new features/enhancements go into a 1.2.x release, or is it strictly bug fixes? What we've talked about before is along these lines: Within the 1.2.x series, it's fine to fix bugs and add new stuff, but not fine to make any backwards-incompatible changes. For a 1.3.x series, we could be more liberal about adding new stuff, and possibly have some deprecations in 1.2.x that get removed -- but it shoujld in general be based on similar enough architectural principles that there be a clear upgrade path. The challenge, of course, is when do you make that split for the evolutionary path? I'd say that something as fundamental as using Struts Chain instead of the monolithic RequestProcessor, and the other changes we could make as a result of having that, would be good grounds for a 1.3.x series. If that were to start in the short term, then thinking of 1.2.x as being in maintenance mode seems likely (although if there's willingness to port features back and forth, it need not go that way immediately ... for example, Tomcat 4.1.x continued to develop for a little while at the beginning of 5.0.x, including some features ported back and forth, but this pretty much stopped as soon as there was a solid 5.0.x release for people to use). For a 2.x chain, we could have the freedom to be somewhat more aggressive at rearchitecting (if we'd known then what we know now, what would Struts have looked like?), and could in theory have a series of alpha releases in parallel with stable releases on 1.2 or 1.3. As others have pointed out, how much simultanaeity there is, and how often releases happen, is more based on the directed energy of the committers (and what they want to work on), and less on whether there are parallel development efforts going on. The reason I ask is because I would love releases much, much more often, but as have been pointed out, incompatibilities/quirks between minor versions could be a disaster. Historically, I'd say our 1.0 - 1.1 transition was, in terms of interoperability and upgrade, a bit on the edge of what most users liked, while the 1.1 - 1.2 transition was much easier to do. We haven't actually gotten around to many x.y.z releases on 1.0 or 1.1, so having them happen at all in 1.2 should be a refreshing change :-). But I agree with you that compatibility is especially important within an x.y release cycle. \Anders Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e
Re: CVS - SVN / Roadmap
On Thu, 14 Oct 2004 14:46:43 -0400, James Mitchell [EMAIL PROTECTED] wrote: Are we not waiting for Ted's update? I haven't seen any commits come across and I assumed he would do it this weekendis this still true Ted? Yes, we should wait for Ted's updates. We do need to get the docs switched over to talk about SVN rather than CVS. -- Martin Cooper -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Don Brown [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, October 14, 2004 1:49 PM Subject: Re: CVS - SVN / Roadmap Deal. Roll it James :) I'll integrate struts-chain and bring over struts-flow and struts-bsf as soon James cuts the release and creates the 1.2.x branch. Don Martin Cooper wrote: On Thu, 14 Oct 2004 08:30:38 -0700, Don Brown [EMAIL PROTECTED] wrote: Ted Husted wrote: +1 Let's stick to the roadmap we laid out in July. http://struts.apache.org/roadmap.html I'll update the site to reflect the CVS/SVN changes this weekend and bring the roadmap page up to date. If James is up for rolling a 1.2.5 release, that's fine with me. Either way, it may be time to call 1.2.x a branch and dub the head 1.3.x, and bring down that-there Struts Chain gizmo. :) +1 I vote we (or perhaps I specifically) integrate struts-chain this weekend. It is stable, and I've been using it in production for some time without problems. Course that also means we (again, perhaps I specifically) should release commons-chain 1.0. Ted, there are a few Guinnesses in it if you help me with the documentation :) How about we roll 1.2.5 first, to capture the latest stuff in a 1.2.x build, then create a 1.2.x branch at that tag, and then roll in the chain stuff as the first step on the 1.3.x ladder? -- Martin Cooper And if Don wants to start setting up struts-flow and struts-scripting along the same lines as struts-faces, I'll buy him a Guiness (or three) at ApacheCon :) Ah, Guinness - the ultimate currency. You got yourself a deal. Don -Ted. On Wed, 13 Oct 2004 13:45:58 -0700, Craig McClanahan wrote: On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein [EMAIL PROTECTED] wrote: Forgive my possible ignorance, but what is the policy on new releases? I've understood that we can release whenever we want, that version numbers are cheap and that you vote whether to make a release alpha/beta/GA. But, what goes into a release? Does new features/enhancements go into a 1.2.x release, or is it strictly bug fixes? What we've talked about before is along these lines: Within the 1.2.x series, it's fine to fix bugs and add new stuff, but not fine to make any backwards-incompatible changes. For a 1.3.x series, we could be more liberal about adding new stuff, and possibly have some deprecations in 1.2.x that get removed -- but it shoujld in general be based on similar enough architectural principles that there be a clear upgrade path. The challenge, of course, is when do you make that split for the evolutionary path? I'd say that something as fundamental as using Struts Chain instead of the monolithic RequestProcessor, and the other changes we could make as a result of having that, would be good grounds for a 1.3.x series. If that were to start in the short term, then thinking of 1.2.x as being in maintenance mode seems likely (although if there's willingness to port features back and forth, it need not go that way immediately ... for example, Tomcat 4.1.x continued to develop for a little while at the beginning of 5.0.x, including some features ported back and forth, but this pretty much stopped as soon as there was a solid 5.0.x release for people to use). For a 2.x chain, we could have the freedom to be somewhat more aggressive at rearchitecting (if we'd known then what we know now, what would Struts have looked like?), and could in theory have a series of alpha releases in parallel with stable releases on 1.2 or 1.3. As others have pointed out, how much simultanaeity there is, and how often releases happen, is more based on the directed energy of the committers (and what they want to work on), and less on whether there are parallel development efforts going on. The reason I ask is because I would love releases much, much more often, but as have been pointed out, incompatibilities/quirks between minor versions could be a disaster. Historically, I'd say our 1.0 - 1.1 transition was, in terms of interoperability and upgrade, a bit on the edge of what most users liked, while the 1.1 - 1.2 transition was much easier to do. We haven't actually gotten around to many x.y.z releases
Re: CVS - SVN / Roadmap
I don't mind making those CVS to SVN documentation updates today. One question though, are we assuming people checked Struts trunk out or the entire Struts repository? This affects whether we refer to a file as trunk/build.xml or just build.xml. Don Martin Cooper wrote: On Thu, 14 Oct 2004 14:46:43 -0400, James Mitchell [EMAIL PROTECTED] wrote: Are we not waiting for Ted's update? I haven't seen any commits come across and I assumed he would do it this weekendis this still true Ted? Yes, we should wait for Ted's updates. We do need to get the docs switched over to talk about SVN rather than CVS. -- Martin Cooper -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Don Brown [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, October 14, 2004 1:49 PM Subject: Re: CVS - SVN / Roadmap Deal. Roll it James :) I'll integrate struts-chain and bring over struts-flow and struts-bsf as soon James cuts the release and creates the 1.2.x branch. Don Martin Cooper wrote: On Thu, 14 Oct 2004 08:30:38 -0700, Don Brown [EMAIL PROTECTED] wrote: Ted Husted wrote: +1 Let's stick to the roadmap we laid out in July. http://struts.apache.org/roadmap.html I'll update the site to reflect the CVS/SVN changes this weekend and bring the roadmap page up to date. If James is up for rolling a 1.2.5 release, that's fine with me. Either way, it may be time to call 1.2.x a branch and dub the head 1.3.x, and bring down that-there Struts Chain gizmo. :) +1 I vote we (or perhaps I specifically) integrate struts-chain this weekend. It is stable, and I've been using it in production for some time without problems. Course that also means we (again, perhaps I specifically) should release commons-chain 1.0. Ted, there are a few Guinnesses in it if you help me with the documentation :) How about we roll 1.2.5 first, to capture the latest stuff in a 1.2.x build, then create a 1.2.x branch at that tag, and then roll in the chain stuff as the first step on the 1.3.x ladder? -- Martin Cooper And if Don wants to start setting up struts-flow and struts-scripting along the same lines as struts-faces, I'll buy him a Guiness (or three) at ApacheCon :) Ah, Guinness - the ultimate currency. You got yourself a deal. Don -Ted. On Wed, 13 Oct 2004 13:45:58 -0700, Craig McClanahan wrote: On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein [EMAIL PROTECTED] wrote: Forgive my possible ignorance, but what is the policy on new releases? I've understood that we can release whenever we want, that version numbers are cheap and that you vote whether to make a release alpha/beta/GA. But, what goes into a release? Does new features/enhancements go into a 1.2.x release, or is it strictly bug fixes? What we've talked about before is along these lines: Within the 1.2.x series, it's fine to fix bugs and add new stuff, but not fine to make any backwards-incompatible changes. For a 1.3.x series, we could be more liberal about adding new stuff, and possibly have some deprecations in 1.2.x that get removed -- but it shoujld in general be based on similar enough architectural principles that there be a clear upgrade path. The challenge, of course, is when do you make that split for the evolutionary path? I'd say that something as fundamental as using Struts Chain instead of the monolithic RequestProcessor, and the other changes we could make as a result of having that, would be good grounds for a 1.3.x series. If that were to start in the short term, then thinking of 1.2.x as being in maintenance mode seems likely (although if there's willingness to port features back and forth, it need not go that way immediately ... for example, Tomcat 4.1.x continued to develop for a little while at the beginning of 5.0.x, including some features ported back and forth, but this pretty much stopped as soon as there was a solid 5.0.x release for people to use). For a 2.x chain, we could have the freedom to be somewhat more aggressive at rearchitecting (if we'd known then what we know now, what would Struts have looked like?), and could in theory have a series of alpha releases in parallel with stable releases on 1.2 or 1.3. As others have pointed out, how much simultanaeity there is, and how often releases happen, is more based on the directed energy of the committers (and what they want to work on), and less on whether there are parallel development efforts going on. The reason I ask is because I would love releases much, much more often, but as have been pointed out, incompatibilities/quirks between minor versions could be a disaster. Historically, I'd say our 1.0 - 1.1 transition was, in terms of interoperability
Re: CVS - SVN / Roadmap
If you just refer to build.xml the docs should apply to a branch as well as they apply to the trunk. But it's worth mentioning trunk in the context of what URL you use to check out the repository in the first place. Craig On Thu, 14 Oct 2004 12:23:42 -0700, Don Brown [EMAIL PROTECTED] wrote: I don't mind making those CVS to SVN documentation updates today. One question though, are we assuming people checked Struts trunk out or the entire Struts repository? This affects whether we refer to a file as trunk/build.xml or just build.xml. Don Martin Cooper wrote: On Thu, 14 Oct 2004 14:46:43 -0400, James Mitchell [EMAIL PROTECTED] wrote: Are we not waiting for Ted's update? I haven't seen any commits come across and I assumed he would do it this weekendis this still true Ted? Yes, we should wait for Ted's updates. We do need to get the docs switched over to talk about SVN rather than CVS. -- Martin Cooper -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Don Brown [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, October 14, 2004 1:49 PM Subject: Re: CVS - SVN / Roadmap Deal. Roll it James :) I'll integrate struts-chain and bring over struts-flow and struts-bsf as soon James cuts the release and creates the 1.2.x branch. Don Martin Cooper wrote: On Thu, 14 Oct 2004 08:30:38 -0700, Don Brown [EMAIL PROTECTED] wrote: Ted Husted wrote: +1 Let's stick to the roadmap we laid out in July. http://struts.apache.org/roadmap.html I'll update the site to reflect the CVS/SVN changes this weekend and bring the roadmap page up to date. If James is up for rolling a 1.2.5 release, that's fine with me. Either way, it may be time to call 1.2.x a branch and dub the head 1.3.x, and bring down that-there Struts Chain gizmo. :) +1 I vote we (or perhaps I specifically) integrate struts-chain this weekend. It is stable, and I've been using it in production for some time without problems. Course that also means we (again, perhaps I specifically) should release commons-chain 1.0. Ted, there are a few Guinnesses in it if you help me with the documentation :) How about we roll 1.2.5 first, to capture the latest stuff in a 1.2.x build, then create a 1.2.x branch at that tag, and then roll in the chain stuff as the first step on the 1.3.x ladder? -- Martin Cooper And if Don wants to start setting up struts-flow and struts-scripting along the same lines as struts-faces, I'll buy him a Guiness (or three) at ApacheCon :) Ah, Guinness - the ultimate currency. You got yourself a deal. Don -Ted. On Wed, 13 Oct 2004 13:45:58 -0700, Craig McClanahan wrote: On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein [EMAIL PROTECTED] wrote: Forgive my possible ignorance, but what is the policy on new releases? I've understood that we can release whenever we want, that version numbers are cheap and that you vote whether to make a release alpha/beta/GA. But, what goes into a release? Does new features/enhancements go into a 1.2.x release, or is it strictly bug fixes? What we've talked about before is along these lines: Within the 1.2.x series, it's fine to fix bugs and add new stuff, but not fine to make any backwards-incompatible changes. For a 1.3.x series, we could be more liberal about adding new stuff, and possibly have some deprecations in 1.2.x that get removed -- but it shoujld in general be based on similar enough architectural principles that there be a clear upgrade path. The challenge, of course, is when do you make that split for the evolutionary path? I'd say that something as fundamental as using Struts Chain instead of the monolithic RequestProcessor, and the other changes we could make as a result of having that, would be good grounds for a 1.3.x series. If that were to start in the short term, then thinking of 1.2.x as being in maintenance mode seems likely (although if there's willingness to port features back and forth, it need not go that way immediately ... for example, Tomcat 4.1.x continued to develop for a little while at the beginning of 5.0.x, including some features ported back and forth, but this pretty much stopped as soon as there was a solid 5.0.x release for people to use). For a 2.x chain, we could have the freedom to be somewhat more aggressive at rearchitecting (if we'd known then what we know now, what would Struts have looked like?), and could in theory have a series of alpha releases in parallel with stable releases on 1.2 or 1.3. As others have pointed out, how much simultanaeity there is, and how often releases happen, is more based on the directed energy of the committers (and what they want
Re: CVS - SVN / Roadmap
All that should remain is updating the roadmap, which I'll leave to folks more involved in the roadmap discussions. If there is anything else, let me know and I'll do it. Don Craig McClanahan wrote: If you just refer to build.xml the docs should apply to a branch as well as they apply to the trunk. But it's worth mentioning trunk in the context of what URL you use to check out the repository in the first place. Craig On Thu, 14 Oct 2004 12:23:42 -0700, Don Brown [EMAIL PROTECTED] wrote: I don't mind making those CVS to SVN documentation updates today. One question though, are we assuming people checked Struts trunk out or the entire Struts repository? This affects whether we refer to a file as trunk/build.xml or just build.xml. Don Martin Cooper wrote: On Thu, 14 Oct 2004 14:46:43 -0400, James Mitchell [EMAIL PROTECTED] wrote: Are we not waiting for Ted's update? I haven't seen any commits come across and I assumed he would do it this weekendis this still true Ted? Yes, we should wait for Ted's updates. We do need to get the docs switched over to talk about SVN rather than CVS. -- Martin Cooper -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Don Brown [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, October 14, 2004 1:49 PM Subject: Re: CVS - SVN / Roadmap Deal. Roll it James :) I'll integrate struts-chain and bring over struts-flow and struts-bsf as soon James cuts the release and creates the 1.2.x branch. Don Martin Cooper wrote: On Thu, 14 Oct 2004 08:30:38 -0700, Don Brown [EMAIL PROTECTED] wrote: Ted Husted wrote: +1 Let's stick to the roadmap we laid out in July. http://struts.apache.org/roadmap.html I'll update the site to reflect the CVS/SVN changes this weekend and bring the roadmap page up to date. If James is up for rolling a 1.2.5 release, that's fine with me. Either way, it may be time to call 1.2.x a branch and dub the head 1.3.x, and bring down that-there Struts Chain gizmo. :) +1 I vote we (or perhaps I specifically) integrate struts-chain this weekend. It is stable, and I've been using it in production for some time without problems. Course that also means we (again, perhaps I specifically) should release commons-chain 1.0. Ted, there are a few Guinnesses in it if you help me with the documentation :) How about we roll 1.2.5 first, to capture the latest stuff in a 1.2.x build, then create a 1.2.x branch at that tag, and then roll in the chain stuff as the first step on the 1.3.x ladder? -- Martin Cooper And if Don wants to start setting up struts-flow and struts-scripting along the same lines as struts-faces, I'll buy him a Guiness (or three) at ApacheCon :) Ah, Guinness - the ultimate currency. You got yourself a deal. Don -Ted. On Wed, 13 Oct 2004 13:45:58 -0700, Craig McClanahan wrote: On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein [EMAIL PROTECTED] wrote: Forgive my possible ignorance, but what is the policy on new releases? I've understood that we can release whenever we want, that version numbers are cheap and that you vote whether to make a release alpha/beta/GA. But, what goes into a release? Does new features/enhancements go into a 1.2.x release, or is it strictly bug fixes? What we've talked about before is along these lines: Within the 1.2.x series, it's fine to fix bugs and add new stuff, but not fine to make any backwards-incompatible changes. For a 1.3.x series, we could be more liberal about adding new stuff, and possibly have some deprecations in 1.2.x that get removed -- but it shoujld in general be based on similar enough architectural principles that there be a clear upgrade path. The challenge, of course, is when do you make that split for the evolutionary path? I'd say that something as fundamental as using Struts Chain instead of the monolithic RequestProcessor, and the other changes we could make as a result of having that, would be good grounds for a 1.3.x series. If that were to start in the short term, then thinking of 1.2.x as being in maintenance mode seems likely (although if there's willingness to port features back and forth, it need not go that way immediately ... for example, Tomcat 4.1.x continued to develop for a little while at the beginning of 5.0.x, including some features ported back and forth, but this pretty much stopped as soon as there was a solid 5.0.x release for people to use). For a 2.x chain, we could have the freedom to be somewhat more aggressive at rearchitecting (if we'd known then what we know now, what would Struts have looked like?), and could in theory have a series of alpha
