[
https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795920#action_12795920
]
Uri Boness commented on SOLR-1602:
----------------------------------
I think it is very important to understand all sides here.
I fully and totally support Chris's attempts to clean up the code base which
rightfully involves moving classes from one package to another. I think in some
cases such cleanups need to come at the cost of user comfort as eventually
they, as users, also gain from it as the system as a whole becomes more robust,
extensible and maintainable. The good thing is that besides the deprecation
issue I believe there is a consensus about the required changes. So thumbs up
Chris!!!
To deprecate or not to deprecate, that is the question. In a widely used
library/framework/system with a large (or fast growing) install/user base such
as the Solr community, the common practice is *not* to just break BWC without
giving the users some grace period in which they can adjust their deployments
to the new changes. Sometimes, it's absolutely necessary (such in the cases of
bug fixes) but when it's not, in general it can create the opposite effect than
you want with the community - instead having the community appreciate your
improvements and see Solr as an "improving with time" product, they turn and
see Solr as an inconsistent and sometime even unreliable product. So from my
experience with delivering goods for the users, especially in the open source
world (and I do have quite a bit of experience in that respect with the Spring
Framework) you always need to strive to 100% BWC in theory and ~95% BWC in
practice (never less than 90% though). If you stick to that, I believe changes
will be widely accepted as improvements rather than harassments.
But there's a catch here!!!! In order to stick to these numbers, you have to
adhere to two important conditions:
1. You need to have a rather solid architecture and code base to start with. If
you don't, then naturally in the beginning you can expect many more
extreme/major changes which lead to quite a few BWC breaks (it will gradually
be reduced as the architecture/codebase improves). Whether Solr answers this
condition is open for debate... there are a lot of solid parts in Solr and
quite a few parts where a complete rewrite is appropriate.
2. You need to have a steady and short release cycles. This is one thing that
Solr lacks... big time. In a 1 year release cycle, deprecating code means that
for the next year (in some cases two years), the code base will be messy with
deprecated classes all over the place. In that respect, I can definitely
understand Chris's objection for deprecation as the cleanup tasks that he's
implementing may end up creating more mess (at least for a long while) than you
had before the cleanup all together. I believe that moving to shorter release
cycles (including bug-fix releases) will greatly help promoting deprecation in
general.
(NOTE: just a small note about the first condition. One thing to take into
account is that *every* piece of software reaches a point in time where it
needs to be completely re-written or at least go through a *major*
refactoring/re-architecturing phase. This can be caused by many factors, let it
be new technologies that are introduced, or simply limitations of the
architecture that were not foreseen. It's very important to understand and
admit to this fact - even from the user point of view it's acceptable. What is
not acceptable, if it happens too many times and too frequent)
Bottom line, it's always a conflict between the user point of view and the
developer point of view. And there needs to be a balance and understanding of
both sides. Each side needs to understand and give in to some extend to create
this balance. But to make it happen, the culture, environment and well defined
policies need to be in place. Arguing endlessly who's right here will never
bring to a good outcome, simply because both sides are right and wrong at the
same time, if you treat it as a black or white issue you'll end up loosing
something - either the user trust or a better software. How about creating a
proper release plan for the upcoming year, say a release every two months?
Chris, if you have such a release schedule, will you feel more comfortable with
deprecation?
> Refactor SOLR package structure to include o.a.solr.response and move
> QueryResponseWriters in there
> ---------------------------------------------------------------------------------------------------
>
> Key: SOLR-1602
> URL: https://issues.apache.org/jira/browse/SOLR-1602
> Project: Solr
> Issue Type: Improvement
> Components: Response Writers
> Affects Versions: 1.2, 1.3, 1.4
> Environment: independent of environment (code structure)
> Reporter: Chris A. Mattmann
> Assignee: Noble Paul
> Fix For: 1.5
>
> Attachments: SOLR-1602.Mattmann.112509.patch.txt,
> SOLR-1602.Mattmann.112509_02.patch.txt, upgrade_solr_config
>
>
> Currently all o.a.solr.request.QueryResponseWriter implementations are
> curiously located in the o.a.solr.request package. Not only is this package
> getting big (30+ classes), a lot of them are misplaced. There should be a
> first-class o.a.solr.response package, and the response related classes
> should be given a home there. Patch forthcoming.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
