geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <>
Subject Re: [VOTE] 1.0.1 Release and the configId issue
Date Fri, 03 Feb 2006 02:57:54 GMT
Sounds good.


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

View raw message