On 2/16/06, Ted Husted <[EMAIL PROTECTED]> wrote: > > If someone is going to manage a 1.2.9 release, then, yes, it would > make sense for someone to make the necessary changes to 1.3 before we > mark it GA. (It just isn't going to be me.) > > But, if we are doing this because it's a security hole (and I don't > agree it is), then we should also patch and re-release Struts 1.1, > which many more people are using. The behavior has existed from day > one; it's not specific to 1.2. Or, if we are saying that 1.2 makes 1.1 > obsolete, then perhaps we should focus on stablizing Struts 1.3 so as > to make 1.2 obsolete too.
If we think this is serious enough to warrant a 1.2.9 release, then it makes little sense to me to tag 1.3.0 without it. Otherwise, all we're saying is "hurrah, we tagged the tree, but oh, you probably don't want to use this because there's a serious problem we know about that we didn't feel like taking the extra time to fix". As for 1.1, personally, I _do_ see 1.2 as making 1.1 "obsolete", so I don't see a need to update that as well. And I would expect 1.3 to make 1.2"obsolete" in time, too. -- Martin Cooper As to any other changes, if Wendy doesn't mind, and someone wants to > make those and also help finish up on the 1.3.0 release, I'm not going > to argue. But, I would have to remove my name as release co-manager, > since I just don't have any more time to spend on 1.3.0 right now. If > someone else can do it, that would be great, it's just that I can't. > > If some people feel these patches are a problem, then we can always > keep Action 1.3.0 as a test-build, until someone has time to apply > them and roll an Action 1.3.1 (note that the other six subprojects > would *not* have to tagged and rolled again, only the one we change). > > The important thing, I think, is to get past the point having to > release everything all at once. Then we can address any other issues > in an agile, release-often, way. Otherwise, it will always be > something, and a week will turn into a month, which turns into another > quarter. > > -Ted. > > On 2/16/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > My view is that this is "security hole" that we are fixing, not adding > > a new feature. I also think that the original RequestProcessor and > > TilesRequestProcessor offer people a way of upgrading to 1.3 and use > > tried and tested code - without having to adopt the CoR > > implementation. > > > > Since I have implemented the Cancellable behaviour in the 1.2.x > > branch, then either it needs also applying to the 1.3 branch or that > > change needs to be reversed. > > > > We probably should release a Struts 1.2.9 to fix this issue and the > > "DOS attack" issue and I am willing to do that - probably have time in > > a couple of weeks. > > > > > If this change prompts anyone to change their vote, please chime-in > > > now. A release plan is a majority vote, so we need three binding +1s > > > from PMC members and more binding +1s than -1s. A +1 here is on the > > > tagging the repository. A quality vote would follow once the test > > > builds are posted. > > > > I realize the plan vote and quality vote are separte issues, but IMO > > the DOS attack bug is v.serious - you can stop a whole web app from > > working using it - and I don't understand why were not fixing it in > > 1.3.0. IMO 1.3.0 is never going to be more than a beta with this "DOS > > attack" bug - or with the original request processor "cancellable" > > security hole. Both are really bad. > > > > Niall > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
