[VOTE] Release Solr 1.4.0

[Grant Ingersoll-6]

Tis the season for releases...

Please vote on releasing the Solr 1.4.0 artifacts located at http://people.apache.org/~gsingers/solr/1.4.0/ 
   (note, solr.tar and solr-maven.tar are not artifacts to be released)

CHANGES are spelled out at https://svn.apache.org/repos/asf/lucene/solr/branches/branch-1.4/CHANGES.txt

Thanks,
Grant

[Yonik Seeley-2]

Hmmm, weren't you going to update the version numbers to 1.4.1-dev
like we just discussed in the other thread?
That way if someone changes some of the solr source from the download
and recompiles, they don't get a version number of 1.4.0

-Yonik
http://www.lucidimagination.com



On Mon, Oct 26, 2009 at 6:15 PM, Grant Ingersoll <gsingers@...> wrote:

> Tis the season for releases...
>
> Please vote on releasing the Solr 1.4.0 artifacts located at
> http://people.apache.org/~gsingers/solr/1.4.0/  (note, solr.tar and
> solr-maven.tar are not artifacts to be released)
>
> CHANGES are spelled out at
> https://svn.apache.org/repos/asf/lucene/solr/branches/branch-1.4/CHANGES.txt
>
> Thanks,
> Grant
>

[ryantxu]

Also, not sure what the policy is on voting on files where the pom  
still needs to change..

http://people.apache.org/~gsingers/solr/1.4.0/maven/org/apache/solr/solr-core/1.4.0/solr-core-1.4.0.pom
points to:
<dependency>
  <groupId>org.apache.lucene</groupId>
  <artifactId>lucene-analyzers</artifactId>
  <version>2.9.0</version>
</dependency>

But we really want to point to 2.9.1....
I guess we can go ahead and change that even though 2.9.1 does not  
exist in any repository yet?

ryan


On Oct 26, 2009, at 6:35 PM, Yonik Seeley wrote:

> Hmmm, weren't you going to update the version numbers to 1.4.1-dev
> like we just discussed in the other thread?
> That way if someone changes some of the solr source from the download
> and recompiles, they don't get a version number of 1.4.0
>
> -Yonik
> http://www.lucidimagination.com
>
>
>
> On Mon, Oct 26, 2009 at 6:15 PM, Grant Ingersoll  
> <gsingers@...> wrote:
>> Tis the season for releases...
>>
>> Please vote on releasing the Solr 1.4.0 artifacts located at
>> http://people.apache.org/~gsingers/solr/1.4.0/  (note, solr.tar and
>> solr-maven.tar are not artifacts to be released)
>>
>> CHANGES are spelled out at
>> https://svn.apache.org/repos/asf/lucene/solr/branches/branch-1.4/CHANGES.txt
>>
>> Thanks,
>> Grant
>>

[Grant Ingersoll-6]

I can do it again.  The generation process is pretty easy now.


On Oct 26, 2009, at 6:42 PM, Ryan McKinley wrote:

> Also, not sure what the policy is on voting on files where the pom  
> still needs to change..
>
> http://people.apache.org/~gsingers/solr/1.4.0/maven/org/apache/solr/solr-core/1.4.0/solr-core-1.4.0.pom
> points to:
> <dependency>
> <groupId>org.apache.lucene</groupId>
> <artifactId>lucene-analyzers</artifactId>
> <version>2.9.0</version>
> </dependency>
>
> But we really want to point to 2.9.1....
> I guess we can go ahead and change that even though 2.9.1 does not  
> exist in any repository yet?
>
> ryan
>
>
> On Oct 26, 2009, at 6:35 PM, Yonik Seeley wrote:
>
>> Hmmm, weren't you going to update the version numbers to 1.4.1-dev
>> like we just discussed in the other thread?
>> That way if someone changes some of the solr source from the download
>> and recompiles, they don't get a version number of 1.4.0
>>
>> -Yonik
>> http://www.lucidimagination.com
>>
>>
>>
>> On Mon, Oct 26, 2009 at 6:15 PM, Grant Ingersoll  
>> <gsingers@...> wrote:
>>> Tis the season for releases...
>>>
>>> Please vote on releasing the Solr 1.4.0 artifacts located at
>>> http://people.apache.org/~gsingers/solr/1.4.0/  (note, solr.tar and
>>> solr-maven.tar are not artifacts to be released)
>>>
>>> CHANGES are spelled out at
>>> https://svn.apache.org/repos/asf/lucene/solr/branches/branch-1.4/CHANGES.txt
>>>
>>> Thanks,
>>> Grant
>>>

[Grant Ingersoll-6]

Yes.

I need to update the POMs too, so scratch this vote for a little bit.

On Oct 26, 2009, at 6:35 PM, Yonik Seeley wrote:

> Hmmm, weren't you going to update the version numbers to 1.4.1-dev
> like we just discussed in the other thread?
> That way if someone changes some of the solr source from the download
> and recompiles, they don't get a version number of 1.4.0
>
> -Yonik
> http://www.lucidimagination.com
>
>
>
> On Mon, Oct 26, 2009 at 6:15 PM, Grant Ingersoll  
> <gsingers@...> wrote:
>> Tis the season for releases...
>>
>> Please vote on releasing the Solr 1.4.0 artifacts located at
>> http://people.apache.org/~gsingers/solr/1.4.0/  (note, solr.tar and
>> solr-maven.tar are not artifacts to be released)
>>
>> CHANGES are spelled out at
>> https://svn.apache.org/repos/asf/lucene/solr/branches/branch-1.4/CHANGES.txt
>>
>> Thanks,
>> Grant
>>

[Grant Ingersoll-6]

OK, take two is up in the same place.  Please vote.

On Oct 26, 2009, at 6:15 PM, Grant Ingersoll wrote:

> Tis the season for releases...
>
> Please vote on releasing the Solr 1.4.0 artifacts located at http://people.apache.org/~gsingers/solr/1.4.0/ 
>   (note, solr.tar and solr-maven.tar are not artifacts to be released)
>
> CHANGES are spelled out at https://svn.apache.org/repos/asf/lucene/solr/branches/branch-1.4/CHANGES.txt
>
> Thanks,
> Grant

[Yonik Seeley-2]

On Mon, Oct 26, 2009 at 9:58 PM, Grant Ingersoll <gsingers@...> wrote:
> OK, take two is up in the same place.  Please vote.

I'm seeing emptiness at
http://people.apache.org/~gsingers/solr/1.4.0/

-Yonik
http://www.lucidimagination.com

> On Oct 26, 2009, at 6:15 PM, Grant Ingersoll wrote:
>
>> Tis the season for releases...
>>
>> Please vote on releasing the Solr 1.4.0 artifacts located at
>> http://people.apache.org/~gsingers/solr/1.4.0/  (note, solr.tar and
>> solr-maven.tar are not artifacts to be released)
>>
>> CHANGES are spelled out at
>> https://svn.apache.org/repos/asf/lucene/solr/branches/branch-1.4/CHANGES.txt
>>
>> Thanks,
>> Grant
>
>
>

[Grant Ingersoll-6]

I'm feeling emptiness, too.  Looks like I forgot the public_html part  
when copying.  All is restored now.


On Oct 26, 2009, at 10:14 PM, Yonik Seeley wrote:

> On Mon, Oct 26, 2009 at 9:58 PM, Grant Ingersoll  
> <gsingers@...> wrote:
>> OK, take two is up in the same place.  Please vote.
>
> I'm seeing emptiness at
> http://people.apache.org/~gsingers/solr/1.4.0/
>
> -Yonik
> http://www.lucidimagination.com
>
>
>> On Oct 26, 2009, at 6:15 PM, Grant Ingersoll wrote:
>>
>>> Tis the season for releases...
>>>
>>> Please vote on releasing the Solr 1.4.0 artifacts located at
>>> http://people.apache.org/~gsingers/solr/1.4.0/  (note, solr.tar and
>>> solr-maven.tar are not artifacts to be released)
>>>
>>> CHANGES are spelled out at
>>> https://svn.apache.org/repos/asf/lucene/solr/branches/branch-1.4/CHANGES.txt
>>>
>>> Thanks,
>>> Grant
>>
>>
>>

[hossman]

: OK, take two is up in the same place.  Please vote.

I thought we'd fixed this, but we still several dependency jars included
multiple times in the release artifacts...

hossman@brunner:~/tmp/solr1.4$ find apache-solr-1.4.0 -name \*.jar | perl -ple 's{.*/}{}' | sort | uniq -c | sort -r | perl -nle 'print unless /^\s*1\s/'
   3 commons-io-1.4.jar
   3 commons-codec-1.3.jar
   2 wstx-asl-3.2.7.jar
   2 slf4j-api-1.5.5.jar
   2 log4j-1.2.14.jar
   2 jcl-over-slf4j-1.5.5.jar
   2 geronimo-stax-api_1.0_spec-1.0.1.jar
   2 commons-lang-2.4.jar
   2 commons-httpclient-3.1.jar

...by itself i wouldn't let that stop us from releasing, but what does
concern me a little bit is that we're also including different versions of
some jars, which seems like it could easily cause some weird errors for
people in some situations...

Using extraction combined with clustering and/or velocity...
apache-solr-1.4.0/contrib/extraction/lib/commons-lang-2.1.jar
apache-solr-1.4.0/contrib/clustering/lib/commons-lang-2.4.jar
apache-solr-1.4.0/contrib/velocity/src/main/solr/lib/commons-lang-2.4.jar

Using extraction in solr...
apache-solr-1.4.0/dist/solrj-lib/geronimo-stax-api_1.0_spec-1.0.1.jar
apache-solr-1.4.0/lib/geronimo-stax-api_1.0_spec-1.0.1.jar
apache-solr-1.4.0/contrib/extraction/lib/geronimo-stax-api_1.0_spec-1.0.jar

Using extraction ... at all ...
apache-solr-1.4.0/contrib/extraction/lib/poi-ooxml-3.5-beta5.jar
apache-solr-1.4.0/contrib/extraction/lib/poi-ooxml-3.5-beta6.jar

This one should actually cause any problems, since the 2.5 copy is just
what jetty uses...
apache-solr-1.4.0/lib/servlet-api-2.4.jar
apache-solr-1.4.0/example/lib/servlet-api-2.5-6.1.3.jar


...does anyone think these are likely to be problematic enough that we
they *must* be fixed before releasing?  
       
        ?

(At a minimum: can someone who is familiar with the velocity code before
test it out in combination with extraction? ... i'm not even sure what to
look for)


-Hoss

[Grant Ingersoll-6]

On Oct 27, 2009, at 3:14 PM, Chris Hostetter wrote:

>
> : OK, take two is up in the same place.  Please vote.
>
> I thought we'd fixed this, but we still several dependency jars  
> included
> multiple times in the release artifacts...
>
> hossman@brunner:~/tmp/solr1.4$ find apache-solr-1.4.0 -name \*.jar |  
> perl -ple 's{.*/}{}' | sort | uniq -c | sort -r | perl -nle 'print  
> unless /^\s*1\s/'
>   3 commons-io-1.4.jar
>   3 commons-codec-1.3.jar
>   2 wstx-asl-3.2.7.jar
>   2 slf4j-api-1.5.5.jar
>   2 log4j-1.2.14.jar
>   2 jcl-over-slf4j-1.5.5.jar
>   2 geronimo-stax-api_1.0_spec-1.0.1.jar
>   2 commons-lang-2.4.jar
>   2 commons-httpclient-3.1.jar
>
> ...by itself i wouldn't let that stop us from releasing, but what does
> concern me a little bit is that we're also including different  
> versions of
> some jars, which seems like it could easily cause some weird errors  
> for
> people in some situations...
>
> Using extraction combined with clustering and/or velocity...
> apache-solr-1.4.0/contrib/extraction/lib/commons-lang-2.1.jar
> apache-solr-1.4.0/contrib/clustering/lib/commons-lang-2.4.jar
> apache-solr-1.4.0/contrib/velocity/src/main/solr/lib/commons-
> lang-2.4.jar
>
> Using extraction in solr...
> apache-solr-1.4.0/dist/solrj-lib/geronimo-stax-api_1.0_spec-1.0.1.jar
> apache-solr-1.4.0/lib/geronimo-stax-api_1.0_spec-1.0.1.jar
> apache-solr-1.4.0/contrib/extraction/lib/geronimo-stax-
> api_1.0_spec-1.0.jar
>
> Using extraction ... at all ...
> apache-solr-1.4.0/contrib/extraction/lib/poi-ooxml-3.5-beta5.jar
> apache-solr-1.4.0/contrib/extraction/lib/poi-ooxml-3.5-beta6.jar
>

Hmm, I thought I removed that one.  beta5 should not be in there.

> This one should actually cause any problems, since the 2.5 copy is  
> just
> what jetty uses...
> apache-solr-1.4.0/lib/servlet-api-2.4.jar
> apache-solr-1.4.0/example/lib/servlet-api-2.5-6.1.3.jar
>
>
> ...does anyone think these are likely to be problematic enough that we
> they *must* be fixed before releasing?
>
> ?
>
> (At a minimum: can someone who is familiar with the velocity code  
> before
> test it out in combination with extraction? ... i'm not even sure  
> what to
> look for)
>
>
> -Hoss
>

--------------------------
Grant Ingersoll
http://www.lucidimagination.com/

Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids)  
using Solr/Lucene:
http://www.lucidimagination.com/search

[hossman]

: Hmm, I thought I removed that one.  beta5 should not be in there.

I see you changed this on the branch .. were you planning on making a new
release candidate?


-Hoss

[Grant Ingersoll-6]

On Oct 27, 2009, at 7:31 PM, Chris Hostetter wrote:

>
> : Hmm, I thought I removed that one.  beta5 should not be in there.
>
> I see you changed this on the branch .. were you planning on making  
> a new
> release candidate?

I'll cut another one.  Although I'm not fixing the other issues.

[Grant Ingersoll-6]

On Oct 27, 2009, at 9:08 PM, Grant Ingersoll wrote:

>
> On Oct 27, 2009, at 7:31 PM, Chris Hostetter wrote:
>
>>
>> : Hmm, I thought I removed that one.  beta5 should not be in there.
>>
>> I see you changed this on the branch .. were you planning on making  
>> a new
>> release candidate?
>
> I'll cut another one.  Although I'm not fixing the other issues.

By other issues, I mean the duplicate libs.  I think we can live with  
them.

[hossman]

: By other issues, I mean the duplicate libs.  I think we can live with them.

I agree ... i would have voted +1 already but i figured based on your
commit you were in the process of doing a new one.



-Hoss

[Grant Ingersoll-6]

OK, new artifacts are up.



On Oct 27, 2009, at 9:51 PM, Chris Hostetter wrote:

>
> : By other issues, I mean the duplicate libs.  I think we can live  
> with them.
>
> I agree ... i would have voted +1 already but i figured based on your
> commit you were in the process of doing a new one.
>
>
>
> -Hoss
>

[hossman]

: OK, new artifacts are up.

+1  

And for the record, these are the artifacts my vote is based on...

8166f7f23637fa8a7d84c3cd30aa21ab  apache-solr-1.4.0.tgz
f7ffa8669e12271981c212733bee1ec0  apache-solr-1.4.0.zip





-Hoss

[Erik Hatcher-4]

+1 also

I'll have a look at the duplicate libs issue as soon as I can, but  
won't be until after/during next week (ApacheCon).

        Erik

On Oct 27, 2009, at 10:41 PM, Chris Hostetter wrote:

>
> : OK, new artifacts are up.
>
> +1
>
> And for the record, these are the artifacts my vote is based on...
>
> 8166f7f23637fa8a7d84c3cd30aa21ab  apache-solr-1.4.0.tgz
> f7ffa8669e12271981c212733bee1ec0  apache-solr-1.4.0.zip
>
>
>
>
>
> -Hoss
>

[Noble Paul നോബിള്‍ नोब्ळ्-2]

I shall fix https://issues.apache.org/jira/browse/SOLR-1527 for 1.4 I guess

On Wed, Oct 28, 2009 at 8:20 AM, Erik Hatcher <erik.hatcher@...> wrote:

> +1 also
>
> I'll have a look at the duplicate libs issue as soon as I can, but won't be
> until after/during next week (ApacheCon).
>
>        Erik
>
> On Oct 27, 2009, at 10:41 PM, Chris Hostetter wrote:
>
>>
>> : OK, new artifacts are up.
>>
>> +1
>>
>> And for the record, these are the artifacts my vote is based on...
>>
>> 8166f7f23637fa8a7d84c3cd30aa21ab  apache-solr-1.4.0.tgz
>> f7ffa8669e12271981c212733bee1ec0  apache-solr-1.4.0.zip
>>
>>
>>
>>
>>
>> -Hoss
>>
>
>

--
-----------------------------------------------------
Noble Paul | Principal Engineer| AOL | http://aol.com

[Yonik Seeley-2]

2009/10/27 Noble Paul നോബിള്‍  नोब्ळ् <noble.paul@...>:
> I shall fix https://issues.apache.org/jira/browse/SOLR-1527 for 1.4 I guess

Perhaps we should just document this?
It's not a regression, but a new, non-core feature.  If we delay every
time we find a bug, this release will never end.

-Yonik
http://www.lucidimagination.com

[hossman]

: It's not a regression, but a new, non-core feature.  If we delay every
: time we find a bug, this release will never end.

agreed.



-Hoss