You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by Ryan McKinley <ry...@gmail.com> on 2008/08/09 04:59:04 UTC
CHANGES.txt
Hello-
Otis pointed out (via direct email) that I have not added many notes
in CHANGES.txt recently. I may be getting slopy, but I also remember
some discussion about how to use changes.txt a while back and figure
we should revist it to make sure everything necessary is in there
before 1.3.
My understanding is that CHANGES.txt is for folks following what has
happened between releases -- it does not need to include internal
modifications if there is no impact on the user.
For example, SOLR-493 is not there since it fixes an issue introduced
since 1.2 -- using CHANGES.txt to say what happened in SOLR-142 had
some side-effects that we now have cleared up seems overly complicated
for anyone following. Likewise the recent changes/modifictions to the
UpdateRequestProcessor framework.
Is this understanding correct?
Are there more (or fewer) things we should include in CHANGES.txt?
ryan
Re: CHANGES.txt
Posted by Shalin Shekhar Mangar <sh...@gmail.com>.
Ok, just to summarize: We will maintain separate changelogs for both SolrJ
and DIH. We should also make sure these changelogs are included in the
nightly tarballs.
Even if they are internal changes, no harm in documenting them in a single
place. Besides it is the only place where we give credit to our contributors
in a proper fashion.
So should we move all SolrJ and DIH related changes to their respective
changelogs? I share Otis's concern on the inflating main changelog file.
On Fri, Aug 15, 2008 at 2:11 AM, Ryan McKinley <ry...@gmail.com> wrote:
> I think an independent location for solrj changes is a good thing. They
> are not relevant for anyone using any other client... the ruby client has
> its own changelog. Solrj is a bit strange though since it is used within
> the SearchComponents.
>
> Since solrj has not yet been released, the coverage in CHANGES.txt it a bit
> limited -- i don't think it is important for to follow all the internal
> changes.
>
> Re independent change log for DIH? that sounds good to me.
>
> ryan
>
>
--
Regards,
Shalin Shekhar Mangar.
Re: CHANGES.txt
Posted by Koji Sekiguchi <ko...@r.email.ne.jp>.
For the solr-ruby version, I'll take a poll on solr-user and ruby-dev as
soon as I pick up options I'm thinking now.
Koji
Erik Hatcher wrote:
>
> On Aug 16, 2008, at 10:52 PM, Koji Sekiguchi wrote:
>> BTW, latest solr-ruby version is v0.0.6. How about v1.0 or v1.3 when
>> solr 1.3 is released?
>
> I don't have any strong opinion on that. Since solr-ruby will ship
> (it gets packaged, right?) with Solr 1.3 distribution, the version
> that it ships with should be considered the official one for that
> release.
>
> How Apache releases and rubyforge gem releases sync.... I'm not yet
> sure how we should do that.
>
> Unfortunately I haven't been doing very much Ruby lately. The active
> folks in solr-ruby get to make the decisions... so whatever you feel
> is best I'm fine with for now. :)
>
> Erik
>
>
Re: CHANGES.txt
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Aug 16, 2008, at 10:52 PM, Koji Sekiguchi wrote:
> BTW, latest solr-ruby version is v0.0.6. How about v1.0 or v1.3 when
> solr 1.3 is released?
I don't have any strong opinion on that. Since solr-ruby will ship
(it gets packaged, right?) with Solr 1.3 distribution, the version
that it ships with should be considered the official one for that
release.
How Apache releases and rubyforge gem releases sync.... I'm not yet
sure how we should do that.
Unfortunately I haven't been doing very much Ruby lately. The active
folks in solr-ruby get to make the decisions... so whatever you feel
is best I'm fine with for now. :)
Erik
Re: CHANGES.txt
Posted by Koji Sekiguchi <ko...@r.email.ne.jp>.
>> I've created client/ruby/CHANGES.txt to care for both solr-ruby and
flare.
> What?! No rake task to generate it from the YAML? ;)
After all, I'd like to maintain client/ruby/solr-ruby/CHANGES.yml rather
than client/ruby/CHANGES.txt.
Now I delete CHANGES.txt:
$ svn commit
Deleting client/ruby/CHANGES.txt
Sending client/ruby/solr-ruby
Committed revision 686583.
BTW, latest solr-ruby version is v0.0.6. How about v1.0 or v1.3 when
solr 1.3 is released?
Koji
Re: CHANGES.txt
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Aug 16, 2008, at 7:45 AM, Koji Sekiguchi wrote:
> I've created client/ruby/CHANGES.txt to care for both solr-ruby and
> flare.
What?! No rake task to generate it from the YAML? ;)
just teasin...
Erik
Re: CHANGES.txt
Posted by Koji Sekiguchi <ko...@r.email.ne.jp>.
I've created client/ruby/CHANGES.txt to care for both solr-ruby and flare.
Koji
Erik Hatcher wrote:
>
> On Aug 14, 2008, at 10:40 PM, Koji Sekiguchi wrote:
>
>> > the ruby client has its own changelog.
>>
>> Oops. I wasn't aware of it's existence. But it's name is CHANGES.yml,
>> not CHANGES.txt,
>> and the contents look like gem update info maintained by Erik.
>>
>> If Solrj and DIH have their own CHANGES.txt, should solr-ruby have
>> its CHANGES.txt?
>
> CHANGES.yml was just me being different and having a structured usable
> change log, just showing off. it's manually maintained and isn't
> being used for gems per se (other than manually copying/pasting the
> log over into rubyforge's form when pushing a new gem).
>
> i dunno, i kinda like CHANGES.yml myself, but i'm not doing near as
> much Ruby as I'd like these days so whoever has a scratch to itch down
> there, go for it.
>
> Erik
>
>
Re: CHANGES.txt
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Aug 14, 2008, at 10:40 PM, Koji Sekiguchi wrote:
> > the ruby client has its own changelog.
>
> Oops. I wasn't aware of it's existence. But it's name is
> CHANGES.yml, not CHANGES.txt,
> and the contents look like gem update info maintained by Erik.
>
> If Solrj and DIH have their own CHANGES.txt, should solr-ruby have
> its CHANGES.txt?
CHANGES.yml was just me being different and having a structured usable
change log, just showing off. it's manually maintained and isn't
being used for gems per se (other than manually copying/pasting the
log over into rubyforge's form when pushing a new gem).
i dunno, i kinda like CHANGES.yml myself, but i'm not doing near as
much Ruby as I'd like these days so whoever has a scratch to itch down
there, go for it.
Erik
Re: CHANGES.txt
Posted by Koji Sekiguchi <ko...@r.email.ne.jp>.
> the ruby client has its own changelog.
Oops. I wasn't aware of it's existence. But it's name is CHANGES.yml,
not CHANGES.txt,
and the contents look like gem update info maintained by Erik.
If Solrj and DIH have their own CHANGES.txt, should solr-ruby have its
CHANGES.txt?
Koji
Ryan McKinley wrote:
> I think an independent location for solrj changes is a good thing.
> They are not relevant for anyone using any other client... the ruby
> client has its own changelog. Solrj is a bit strange though since it
> is used within the SearchComponents.
>
> Since solrj has not yet been released, the coverage in CHANGES.txt it
> a bit limited -- i don't think it is important for to follow all the
> internal changes.
>
> Re independent change log for DIH? that sounds good to me.
>
> ryan
Re: CHANGES.txt
Posted by Ryan McKinley <ry...@gmail.com>.
I think an independent location for solrj changes is a good thing.
They are not relevant for anyone using any other client... the ruby
client has its own changelog. Solrj is a bit strange though since it
is used within the SearchComponents.
Since solrj has not yet been released, the coverage in CHANGES.txt it
a bit limited -- i don't think it is important for to follow all the
internal changes.
Re independent change log for DIH? that sounds good to me.
ryan
On Aug 14, 2008, at 4:27 PM, Shalin Shekhar Mangar wrote:
> On a related note, I can see a CHANGES.txt inside client/java/solrj
> folder.
> However, it has not been updated with many changes that have took
> place in
> Solrj. I wasn't even aware of it's existence until recently.
>
> Two options:
> 1. We merge it with the main changelog file and delete it
> 2. We gather all SolrJ changes from the main changelog and put it here
>
> If we decide to go for the 2nd route, is a separate changelog needed
> for DIH
> as well?
>
> On Sat, Aug 9, 2008 at 8:29 AM, Ryan McKinley <ry...@gmail.com>
> wrote:
>
>> Hello-
>>
>> Otis pointed out (via direct email) that I have not added many
>> notes in
>> CHANGES.txt recently. I may be getting slopy, but I also remember
>> some
>> discussion about how to use changes.txt a while back and figure we
>> should
>> revist it to make sure everything necessary is in there before 1.3.
>>
>> My understanding is that CHANGES.txt is for folks following what has
>> happened between releases -- it does not need to include internal
>> modifications if there is no impact on the user.
>>
>> For example, SOLR-493 is not there since it fixes an issue
>> introduced since
>> 1.2 -- using CHANGES.txt to say what happened in SOLR-142 had some
>> side-effects that we now have cleared up seems overly complicated
>> for anyone
>> following. Likewise the recent changes/modifictions to the
>> UpdateRequestProcessor framework.
>>
>> Is this understanding correct?
>>
>> Are there more (or fewer) things we should include in CHANGES.txt?
>>
>> ryan
>
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
Re: CHANGES.txt
Posted by Shalin Shekhar Mangar <sh...@gmail.com>.
On a related note, I can see a CHANGES.txt inside client/java/solrj folder.
However, it has not been updated with many changes that have took place in
Solrj. I wasn't even aware of it's existence until recently.
Two options:
1. We merge it with the main changelog file and delete it
2. We gather all SolrJ changes from the main changelog and put it here
If we decide to go for the 2nd route, is a separate changelog needed for DIH
as well?
On Sat, Aug 9, 2008 at 8:29 AM, Ryan McKinley <ry...@gmail.com> wrote:
> Hello-
>
> Otis pointed out (via direct email) that I have not added many notes in
> CHANGES.txt recently. I may be getting slopy, but I also remember some
> discussion about how to use changes.txt a while back and figure we should
> revist it to make sure everything necessary is in there before 1.3.
>
> My understanding is that CHANGES.txt is for folks following what has
> happened between releases -- it does not need to include internal
> modifications if there is no impact on the user.
>
> For example, SOLR-493 is not there since it fixes an issue introduced since
> 1.2 -- using CHANGES.txt to say what happened in SOLR-142 had some
> side-effects that we now have cleared up seems overly complicated for anyone
> following. Likewise the recent changes/modifictions to the
> UpdateRequestProcessor framework.
>
> Is this understanding correct?
>
> Are there more (or fewer) things we should include in CHANGES.txt?
>
> ryan
--
Regards,
Shalin Shekhar Mangar.
Re: CHANGES.txt
Posted by Yonik Seeley <yo...@apache.org>.
On Fri, Aug 8, 2008 at 10:59 PM, Ryan McKinley <ry...@gmail.com> wrote:
> My understanding is that CHANGES.txt is for folks following what has
> happened between releases -- it does not need to include internal
> modifications if there is no impact on the user.
Correct.
I sometimes add an entry anyway if the changes are non-trivial and by
someone who hasn't received much credit yet. If it fits under a
previous entry, I've also just added their name to the list of
contributors for that feature.
-Yonik
Re: CHANGES.txt
Posted by Chris Hostetter <ho...@fucit.org>.
: My understanding is that CHANGES.txt is for folks following what has happened
: between releases -- it does not need to include internal modifications if
: there is no impact on the user.
the one thing to keep in mind is that people trying out nightly builds
also take advantage of CHANGES.txt to know what to expect ... they can
test the fix, or pay attention to wether the fix had some side affect on
the functionality, etc...
: Are there more (or fewer) things we should include in CHANGES.txt?
In the specific case of SOLR-493, it would probably make sense to add a
note to the CHANGES.txt entry for SOLR-142 saying that if there is a
<gettableFiles> section an instance of ShowFileRequestHandler will be
registered automaticly.
-Hoss