Looking back to 2.0.x

["Jay D. McHugh" <ja...@gmail.com>]

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).

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).

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.

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.

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?


Jay

Re: Looking back to 2.0.x

[Donald Woods <dw...@apache.org>]

Officially announcing that 2.0.3 will be the last planned 2.0 release 
would be a good move and will help our users to start looking at using a 
2.1.x release for new projects.

We'll also want to steer Eclipse users off of GEP 2.0.x and onto GEP 
2.1.3, which still supports 2.0.x servers and includes Eclipse Ganymede 
support (which GEP 2.0.x doesn't have.)


-Donald


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).
> 
> 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).
> 
> 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.
> 
> 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.
> 
> 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?
> 
> 
> Jay
> 

Re: Looking back to 2.0.x

[Donald Woods <dw...@apache.org>]

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....


-Donald


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
>>
> 

Re: Looking back to 2.0.x

["Jay D. McHugh" <ja...@gmail.com>]

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
> 

Re: Looking back to 2.0.x

[Kevan Miller <ke...@gmail.com>]

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