geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <>
Subject Re: Looking back to 2.0.x
Date Mon, 20 Oct 2008 18:45:21 GMT
Looks like you'll also have to release org.apache.geronimo.components
and we should probably upgrade to the latest released artifacts for 
Javamail and any of the Specs....


Jay D. McHugh wrote:
> 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

View raw message