geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: [VOTE] 1.0.1 Release and the configId issue
Date Fri, 03 Feb 2006 00:38:53 GMT
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 <jrsisson@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.
> >
> >
>
>

Mime
View raw message