On 2/2/06, Matt Hogstrom [EMAIL PROTECTED] 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
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
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
[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
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
[X] +1 Document issue in release notes and defer fix to 1.1
Regards,
Alan
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
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
[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
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
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
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
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
13 matches
Mail list logo
