geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sisson <>
Subject Re: [VOTE] 1.0.1 Release and the configId issue
Date Thu, 02 Feb 2006 23:55:54 GMT
[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