You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Matt Hogstrom <ma...@hogstrom.org> on 2006/02/02 06:48:54 UTC
[VOTE] 1.0.1 Release and the configId issue
There was some discussion on Irc earlier this week about the issue related to
plans having to be changed due to module versions changing. This is clearly
going to be a significant issues for customers as they will have to re-work all
their plans on incremental server changes. Although these will most likely be
tolerated in the short-term this is a serious shortcoming in the current design
that needs to be addressed.
During the discussion it was asserted tha given the magnitude of the change to
the format of the plans and changes to G it was not appropriate for make this
change in a maintenance release. The collective wisdom was to declare in the
release notes this issue and give the user guidance with the assurance this is
being addressed in 1.1 (or there abouts).
Since there has been a lot of discussion about this already and it being such a
significant issue I thought I'd request a vote to see where we stand.
[ ] +1 Document issue in release notes and defer fix to 1.1
[ ] 0 Not that important one way or another
[ ] -1 This is an issue that must be resolved in the 1.0.x branch
[ ] Other...provide your reasons.
Re: [VOTE] 1.0.1 Release and the configId issue
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
If we are going to do a 1.0.1, I think the least intrusive approach is
to use "1.0" in all the configIds for 1.0.1, which will require a fair
amount of XML work, but few or no code changes.
If this is too much work to be considered for 1.0.1, then I vote to
abandon 1.0.x. What's the point of a maintenance release that isn't
backward compatible?
Thanks,
Aaron
On 2/2/06, David Jencks <da...@yahoo.com> wrote:
> I'd like to see those who vote -1 or "other" provide a suggestion for
> a technical solution for the 1.0 branch, an explanation of how it
> fits into the notion of a third-digit "critical bug fixes only" point
> release, a suggested schedule for implementation, and a suggestion of
> who will work on it. I'm also curious as to whether the suggested
> solution is intended to be compatible with 1.0, a future 1.1 release,
> or both.
>
> I may sound snippy here, in which case I apologize. However, I
> haven't seen anything that I consider realistic planning for getting
> this into 1.0.1. The proposals (mostly dain's) that I have seen and
> that I think might work involve major changes to a lot of the basic
> plumbing of geronimo and are IMNSHO wholly inappropriate to a 1.x.y
> release. Frankly, I think a -1 means a vote to abandon any 1.0.x
> releases.
>
> thanks
> david jencks
>
> On Feb 2, 2006, at 5:39 AM, Aaron Mulder wrote:
>
> > On 2/2/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
> >> [ ] +1 Document issue in release notes and defer fix to 1.1
> >> [ ] 0 Not that important one way or another
> >> [X] -1 This is an issue that must be resolved in the 1.0.x branch
> >> [ ] Other...provide your reasons.
> >
> > Aaron
>
>
Re: [VOTE] 1.0.1 Release and the configId issue
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On 2/2/2006 2:10 PM, Dain Sundstrom wrote:
> On Feb 2, 2006, at 1:17 PM, David Jencks wrote:
>
>> I may sound snippy here, in which case I apologize. However, I
>> haven't seen anything that I consider realistic planning for getting
>> this into 1.0.1. The proposals (mostly dain's) that I have seen and
>> that I think might work involve major changes to a lot of the basic
>> plumbing of geronimo and are IMNSHO wholly inappropriate to a 1.x.y
>> release.
>
>
> I agree. The solution that I have proposed should not be considered
> "maintenance". I would call it major surgery.
>
> Regardless of what we are doing for 1.0.1, I think we need to
> continue the discussion and make an attempt at the fix for 1.1 soon.
These statements reflect my strongly held opinions.
Regards,
Alan
Re: [VOTE] 1.0.1 Release and the configId issue
Posted by Dain Sundstrom <da...@iq80.com>.
On Feb 2, 2006, at 1:17 PM, David Jencks wrote:
> I may sound snippy here, in which case I apologize. However, I
> haven't seen anything that I consider realistic planning for
> getting this into 1.0.1. The proposals (mostly dain's) that I have
> seen and that I think might work involve major changes to a lot of
> the basic plumbing of geronimo and are IMNSHO wholly inappropriate
> to a 1.x.y release.
I agree. The solution that I have proposed should not be considered
"maintenance". I would call it major surgery.
Regardless of what we are doing for 1.0.1, I think we need to
continue the discussion and make an attempt at the fix for 1.1 soon.
-dain
Re: [VOTE] 1.0.1 Release and the configId issue
Posted by David Jencks <da...@yahoo.com>.
I'd like to see those who vote -1 or "other" provide a suggestion for
a technical solution for the 1.0 branch, an explanation of how it
fits into the notion of a third-digit "critical bug fixes only" point
release, a suggested schedule for implementation, and a suggestion of
who will work on it. I'm also curious as to whether the suggested
solution is intended to be compatible with 1.0, a future 1.1 release,
or both.
I may sound snippy here, in which case I apologize. However, I
haven't seen anything that I consider realistic planning for getting
this into 1.0.1. The proposals (mostly dain's) that I have seen and
that I think might work involve major changes to a lot of the basic
plumbing of geronimo and are IMNSHO wholly inappropriate to a 1.x.y
release. Frankly, I think a -1 means a vote to abandon any 1.0.x
releases.
thanks
david jencks
On Feb 2, 2006, at 5:39 AM, Aaron Mulder wrote:
> On 2/2/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
>> [ ] +1 Document issue in release notes and defer fix to 1.1
>> [ ] 0 Not that important one way or another
>> [X] -1 This is an issue that must be resolved in the 1.0.x branch
>> [ ] Other...provide your reasons.
>
> Aaron
Re: [VOTE] 1.0.1 Release and the configId issue
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 2/2/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
> [ ] +1 Document issue in release notes and defer fix to 1.1
> [ ] 0 Not that important one way or another
> [X] -1 This is an issue that must be resolved in the 1.0.x branch
> [ ] Other...provide your reasons.
Aaron
Re: [VOTE] 1.0.1 Release and the configId issue
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
[X] +1 Document issue in release notes and defer fix to 1.1
Regards,
Alan
Re: [VOTE] 1.0.1 Release and the configId issue
Posted by Geir Magnusson Jr <ge...@pobox.com>.
What's the timing? I ask with motivated by the thought that the sooner
it happens, the fewer people will be affected...
geir
Matt Hogstrom wrote:
> There was some discussion on Irc earlier this week about the issue
> related to plans having to be changed due to module versions changing.
> This is clearly going to be a significant issues for customers as they
> will have to re-work all their plans on incremental server changes.
> Although these will most likely be tolerated in the short-term this is a
> serious shortcoming in the current design that needs to be addressed.
>
> During the discussion it was asserted tha given the magnitude of the
> change to the format of the plans and changes to G it was not
> appropriate for make this change in a maintenance release. The
> collective wisdom was to declare in the release notes this issue and
> give the user guidance with the assurance this is being addressed in 1.1
> (or there abouts).
>
> Since there has been a lot of discussion about this already and it being
> such a significant issue I thought I'd request a vote to see where we
> stand.
>
> [ ] +1 Document issue in release notes and defer fix to 1.1
> [ ] 0 Not that important one way or another
> [ ] -1 This is an issue that must be resolved in the 1.0.x branch
> [ ] Other...provide your reasons.
>
>
Re: [VOTE] 1.0.1 Release and the configId issue
Posted by Donald Woods <dr...@yahoo.com>.
Matt Hogstrom wrote:
> There was some discussion on Irc earlier this week about the issue
> related to plans having to be changed due to module versions changing.
> This is clearly going to be a significant issues for customers as they
> will have to re-work all their plans on incremental server changes.
> Although these will most likely be tolerated in the short-term this is a
> serious shortcoming in the current design that needs to be addressed.
>
> During the discussion it was asserted tha given the magnitude of the
> change to the format of the plans and changes to G it was not
> appropriate for make this change in a maintenance release. The
> collective wisdom was to declare in the release notes this issue and
> give the user guidance with the assurance this is being addressed in 1.1
> (or there abouts).
>
> Since there has been a lot of discussion about this already and it being
> such a significant issue I thought I'd request a vote to see where we
> stand.
>
> [X] +1 Document issue in release notes and defer fix to 1.1
> [ ] 0 Not that important one way or another
> [ ] -1 This is an issue that must be resolved in the 1.0.x branch
> [ ] Other...provide your reasons.
>
>
>
Re: [VOTE] 1.0.1 Release and the configId issue
Posted by David Jencks <da...@yahoo.com>.
> [X] +1 Document issue in release notes and defer fix to 1.1
This situation is very unfortunate, but I don't think fixing this can
possible be justified in a 1.0.x point release due to the extensive
modifications of basic geronimo plumbing necessary for a forward
compatible solution, and I don't see anyone willing to work on it for
1.0.1.
thanks
david jencks
On Feb 1, 2006, at 9:48 PM, Matt Hogstrom wrote:
> There was some discussion on Irc earlier this week about the issue
> related to plans having to be changed due to module versions
> changing. This is clearly going to be a significant issues for
> customers as they will have to re-work all their plans on
> incremental server changes. Although these will most likely be
> tolerated in the short-term this is a serious shortcoming in the
> current design that needs to be addressed.
>
> During the discussion it was asserted tha given the magnitude of
> the change to the format of the plans and changes to G it was not
> appropriate for make this change in a maintenance release. The
> collective wisdom was to declare in the release notes this issue
> and give the user guidance with the assurance this is being
> addressed in 1.1 (or there abouts).
>
> Since there has been a lot of discussion about this already and it
> being such a significant issue I thought I'd request a vote to see
> where we stand.
>
> [ ] +1 Document issue in release notes and defer fix to 1.1
> [ ] 0 Not that important one way or another
> [ ] -1 This is an issue that must be resolved in the 1.0.x branch
> [ ] Other...provide your reasons.
>
Re: [VOTE] 1.0.1 Release and the configId issue
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Sounds good.
Regards,
Alan
Aaron Mulder wrote, On 2/2/2006 4:38 PM:
> Just to update, on IRC there is a discussion featuring the option of
> changing the 1.0 branch to become 1.1 and fixing the configId stuff
> properly and permanently there (and of course merging it to HEAD,
> which would become 1.2 or higher). I would be happy with that result,
> as it still gets the maintenance out 'reasonably soon' yet fixes the
> issue without having a separate "short-term fix" and "long-term fix".
> This seems to be popular, and now the discussion has turned to how the
> "right" fix could be implemented (namely, no longer requiring an
> explicit version number declaration, though allowing for one if it's
> desired).
>
> Thanks,
> Aaron
>
> On 2/2/06, John Sisson <jr...@gmail.com> wrote:
>
>>[X] -1 This is an issue that must be resolved in the 1.0.x branch
>>
>>I strongly feel we should not be releasing something that is not
>>backwards compatible. We aren't producing milestone releases any more
>>so we need to be committed to compatibility between releases.
>>
>>If we do ship an incompatible release it may have a negative impact on
>>Geronimo's reputation. Users evaluating Geronimo for deployment will
>>will be deterred with the worry about compatibility being broken again
>>in future releases. I also wouldn't like to hear this being used as FUD
>>against Geronimo by competitive solutions.
>>
>>I also wonder how many articles on Geronimo have been written that would
>>not work.
>>
>>Can we discuss Aarons's suggestion below of using "1.0" in all the
>>configIds for the 1.0.1 release, as It would be a pity to discard all
>>the work that has gone into getting the 1.0.x branch where it is so far.
>>
>>Regards,
>>
>>John
>>
>>Matt Hogstrom wrote:
>>
>>>There was some discussion on Irc earlier this week about the issue
>>>related to plans having to be changed due to module versions
>>>changing. This is clearly going to be a significant issues for
>>>customers as they will have to re-work all their plans on incremental
>>>server changes. Although these will most likely be tolerated in the
>>>short-term this is a serious shortcoming in the current design that
>>>needs to be addressed.
>>>
>>>During the discussion it was asserted tha given the magnitude of the
>>>change to the format of the plans and changes to G it was not
>>>appropriate for make this change in a maintenance release. The
>>>collective wisdom was to declare in the release notes this issue and
>>>give the user guidance with the assurance this is being addressed in
>>>1.1 (or there abouts).
>>>
>>>Since there has been a lot of discussion about this already and it
>>>being such a significant issue I thought I'd request a vote to see
>>>where we stand.
>>>
>>>[ ] +1 Document issue in release notes and defer fix to 1.1
>>>[ ] 0 Not that important one way or another
>>>[ ] -1 This is an issue that must be resolved in the 1.0.x branch
>>>[ ] Other...provide your reasons.
>>>
>>>
>>
>>
Re: [VOTE] 1.0.1 Release and the configId issue
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Just to update, on IRC there is a discussion featuring the option of
changing the 1.0 branch to become 1.1 and fixing the configId stuff
properly and permanently there (and of course merging it to HEAD,
which would become 1.2 or higher). I would be happy with that result,
as it still gets the maintenance out 'reasonably soon' yet fixes the
issue without having a separate "short-term fix" and "long-term fix".
This seems to be popular, and now the discussion has turned to how the
"right" fix could be implemented (namely, no longer requiring an
explicit version number declaration, though allowing for one if it's
desired).
Thanks,
Aaron
On 2/2/06, John Sisson <jr...@gmail.com> wrote:
> [X] -1 This is an issue that must be resolved in the 1.0.x branch
>
> I strongly feel we should not be releasing something that is not
> backwards compatible. We aren't producing milestone releases any more
> so we need to be committed to compatibility between releases.
>
> If we do ship an incompatible release it may have a negative impact on
> Geronimo's reputation. Users evaluating Geronimo for deployment will
> will be deterred with the worry about compatibility being broken again
> in future releases. I also wouldn't like to hear this being used as FUD
> against Geronimo by competitive solutions.
>
> I also wonder how many articles on Geronimo have been written that would
> not work.
>
> Can we discuss Aarons's suggestion below of using "1.0" in all the
> configIds for the 1.0.1 release, as It would be a pity to discard all
> the work that has gone into getting the 1.0.x branch where it is so far.
>
> Regards,
>
> John
>
> Matt Hogstrom wrote:
> > There was some discussion on Irc earlier this week about the issue
> > related to plans having to be changed due to module versions
> > changing. This is clearly going to be a significant issues for
> > customers as they will have to re-work all their plans on incremental
> > server changes. Although these will most likely be tolerated in the
> > short-term this is a serious shortcoming in the current design that
> > needs to be addressed.
> >
> > During the discussion it was asserted tha given the magnitude of the
> > change to the format of the plans and changes to G it was not
> > appropriate for make this change in a maintenance release. The
> > collective wisdom was to declare in the release notes this issue and
> > give the user guidance with the assurance this is being addressed in
> > 1.1 (or there abouts).
> >
> > Since there has been a lot of discussion about this already and it
> > being such a significant issue I thought I'd request a vote to see
> > where we stand.
> >
> > [ ] +1 Document issue in release notes and defer fix to 1.1
> > [ ] 0 Not that important one way or another
> > [ ] -1 This is an issue that must be resolved in the 1.0.x branch
> > [ ] Other...provide your reasons.
> >
> >
>
>
Re: [VOTE] 1.0.1 Release and the configId issue
Posted by John Sisson <jr...@gmail.com>.
[X] -1 This is an issue that must be resolved in the 1.0.x branch
I strongly feel we should not be releasing something that is not
backwards compatible. We aren't producing milestone releases any more
so we need to be committed to compatibility between releases.
If we do ship an incompatible release it may have a negative impact on
Geronimo's reputation. Users evaluating Geronimo for deployment will
will be deterred with the worry about compatibility being broken again
in future releases. I also wouldn't like to hear this being used as FUD
against Geronimo by competitive solutions.
I also wonder how many articles on Geronimo have been written that would
not work.
Can we discuss Aarons's suggestion below of using "1.0" in all the
configIds for the 1.0.1 release, as It would be a pity to discard all
the work that has gone into getting the 1.0.x branch where it is so far.
Regards,
John
Matt Hogstrom wrote:
> There was some discussion on Irc earlier this week about the issue
> related to plans having to be changed due to module versions
> changing. This is clearly going to be a significant issues for
> customers as they will have to re-work all their plans on incremental
> server changes. Although these will most likely be tolerated in the
> short-term this is a serious shortcoming in the current design that
> needs to be addressed.
>
> During the discussion it was asserted tha given the magnitude of the
> change to the format of the plans and changes to G it was not
> appropriate for make this change in a maintenance release. The
> collective wisdom was to declare in the release notes this issue and
> give the user guidance with the assurance this is being addressed in
> 1.1 (or there abouts).
>
> Since there has been a lot of discussion about this already and it
> being such a significant issue I thought I'd request a vote to see
> where we stand.
>
> [ ] +1 Document issue in release notes and defer fix to 1.1
> [ ] 0 Not that important one way or another
> [ ] -1 This is an issue that must be resolved in the 1.0.x branch
> [ ] Other...provide your reasons.
>
>