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 <[EMAIL PROTECTED]> 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.
