Hello All, Since I went ahead and opened my mouth... :)
Is there anyone who really wants one (or more) of the 19 tickets open for 2.0.3 to be closed before a release? And are you willing to work on closing it/them as well? Before anyone answers - I am going to suggest that G-1907 should be a "won't fix" issue. There is the complication that comes into play with apps that have a dependency on the app being redeployed. And, I believe that for the more recent versions (2.1.x) we already decided not to fix this. Does anyone disagree or have a comment? I will start doing the testing to make sure that 2.0.3 still passes the TCK and reading the release documentation. If there are no issues that anyone wants to close - then I will move all of the issues to 2.0.4 at the end of the week and start trying to do the release. If there are any issues that get 'adopted' then we'll figure out a timeframe for them to get fixed/tested and go from there. Jay Kevan Miller wrote: > Hi, Jay. > > On Oct 16, 2008, at 8:28 PM, Jay D. McHugh wrote: > >> Hello all, >> >> With the discussion of where the JEE 6 development will be done, I >> realized (again) that we never released 2.0.3. >> >> The only thing that kept us from releasing 2.0.3 was an exception that >> only occurred under stress testing the server (a >> ConcurrentModificationException). > > We scuttled the whole 1.2 release for similar reasons. Perhaps we should > work on learning from our own history. > >> >> >> And, recently, when we added a number of security patches that were the >> driver for releasing 2.1.3 - the same security patches were put into the >> 2.0.x codestream as well. >> >> Should we put out one last release of 2.0.x and then officially >> encourage anyone on a level lower than 2.1.x to upgrade? I think that >> is probably what we should do. At this point, there is a range of work >> being applied to 2.0.x, 2.1.x, 2.2.x and soon 3.0.x (or however we >> version the upcoming JEE 6). > > If you, and/or some other community member(s), are motivated to prepare > a 2.0.3 release, you'd certainly have my support. I'm sure you'd have > the community's support, also. > > Given the security fixes that you mention, I think it would be nice to > have an actual release that contains them. > >> >> >> Also, do we have an official 'support period'? Would it be worthwhile >> to discuss implementing one if we don't? Letting our users know that we >> intend to support a particular major.minor release (bug fixes only) >> would make it easier for them to plan which version they want to >> implement against and plan/schedule their server upgrades. Maybe we >> would specify a window of '12 months after the next higher minor >> release'. Version 2.1.0 was released this February, so 2.0.x 'official' >> support would end next February. Of course if someone felt like >> continuing to make fixes (and they had someone to run TCKs against them) >> then 'unofficial' support may run longer. > > We've never established an official support period. I'm not too sure > that we need one. If you disagree, then I'm all ears. Or, if our user > community feels that it would be helpful, then I'd certainly give it my > consideration. Personally, I think we've done a pretty good job in > merging fixes back into our older releases. I haven't seen that the lack > of a support policy was inhibiting user adoption. > > As long as we have a stable newer release (e.g. 2.1.x) release to point > to, shifting our focus towards our newer releases doesn't seem too bad > to me. If there had been user requests for a 2.0.x release, I think we > would have generated a new 2.0.x release. > >> >> Our resources are being spread -really- thin. And as a result, 2.0.x >> has been nearly abandoned. We have security fixes that were put in this >> September, but no release in the last 12 months. When 2.2.x is finally >> released and the JEE 6 work begins in earnest - I have a feeling that >> 2.1.x will begin to fall by the wayside as well. > > I expect that you are correct. Personaly, I doubt that we'll ever > maintain more than two release branches simultaneously (e.g. 2.0/2.1, or > 2.1/2.2; etc). > >> >> Regardless - I mainly wanted to know if anyone thought that we should go >> ahead and do a final release on 2.0.x. I think the security fixes make >> it worthwhile. But then, maybe we should officially set an end for 2.0. >> >> Any thoughts? > > I second the motion for Jay to be the release manager... ;-) > > --kevan >
