You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucy.apache.org by Nick Wellnhofer <we...@aevum.de> on 2016/11/23 17:00:27 UTC

[lucy-dev] 0.6.1 release

Lucifers,

I'd like to release 0.6.1 with the following fixes:

 
https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%200.6.1%20AND%20project%20%3D%20CLOWNFISH
 
https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%200.6.1%20AND%20project%20%3D%20LUCY

In the meantime, I uploaded a couple of development releases to CPAN to fix 
failure reports from CPAN Testers. There's one Clownfish issue that is still 
unresolved:

     https://issues.apache.org/jira/browse/CLOWNFISH-109

I added some diagnostics, but unfortunately, I didn't get any more reports 
from the particular tester who encountered the errors.

 
https://github.com/apache/lucy-clownfish/commit/ae83c3eb5948e933b5b19c0dfb87a001815c8355

This might have been caused by the recent cpantesters.org outage.

On the Lucy side, I'd still like to address LUCY-313:

     https://issues.apache.org/jira/browse/LUCY-313

My current plan is:

- Ignore CLOWNFISH-109 for now.
- Fix LUCY-313.
- Upload another Lucy dev release to CPAN.
- If all goes well, create an RC for 0.6.1.

Nick


Re: [lucy-dev] 0.6.1 release

Posted by Nick Wellnhofer <we...@aevum.de>.
On 24/11/2016 17:05, Nick Wellnhofer wrote:
> On 24/11/2016 13:22, Nick Wellnhofer wrote:
>> - remove .pm files for non-public classes,
>
>> The only danger I can see is breaking Perl code that still "use"s
>> an obsolete class.
>
> Hmm, this could also be a problem for people using undocumented classes.
> Here's a list of classes that would be affected:

I kept the .pm files for now. See LUCY-313 for more details.

CLOWNFISH-109 is still unresolved although I got a bit more info.

I published Clownfish 0.6.0.5 and Lucy 0.6.0.4 on CPAN and the results look good:

     http://matrix.cpantesters.org/?dist=Clownfish+0.6.0.5
     http://matrix.cpantesters.org/?dist=Lucy+0.6.0.4

(The Lucy failure should also be fixed in 0.6 and master.)

I think we're ready for a 0.6.1 release candidate next week.

Nick


Re: [lucy-dev] 0.6.1 release

Posted by Nick Wellnhofer <we...@aevum.de>.
On 24/11/2016 13:22, Nick Wellnhofer wrote:
> - remove .pm files for non-public classes,

> The only danger I can see is breaking Perl code that still "use"s
> an obsolete class.

Hmm, this could also be a problem for people using undocumented classes. 
Here's a list of classes that would be affected:

Lucy::Highlight::HeatMap
Lucy::Index::DeletionsReader
Lucy::Index::DocVector
Lucy::Index::DocWriter
Lucy::Index::FilePurger
Lucy::Index::HighlightReader
Lucy::Index::HighlightWriter
Lucy::Index::Inverter
Lucy::Index::LexiconWriter
Lucy::Index::PolyLexicon
Lucy::Index::Posting
Lucy::Index::Posting::MatchPosting
Lucy::Index::Posting::RichPosting
Lucy::Index::Posting::ScorePosting
Lucy::Index::PostingListWriter
Lucy::Index::SegLexicon
Lucy::Index::SegPostingList
Lucy::Index::SortCache
Lucy::Index::SortReader
Lucy::Index::SortWriter
Lucy::Index::TermInfo
Lucy::Index::TermVector
Lucy::Object::Obj
Lucy::Plan::Float32Type
Lucy::Plan::Float64Type
Lucy::Plan::Int32Type
Lucy::Plan::Int64Type
Lucy::Search::ANDMatcher
Lucy::Search::BitVecMatcher
Lucy::Search::Collector::SortCollector
Lucy::Search::HitQueue
Lucy::Search::MatchDoc
Lucy::Search::NOTMatcher
Lucy::Search::ORScorer
Lucy::Search::PolyCompiler
Lucy::Search::RequiredOptionalMatcher
Lucy::Search::TopDocs
Lucy::Store::FSFileHandle
Lucy::Store::FileHandle
Lucy::Store::InStream
Lucy::Store::OutStream
Lucy::Store::RAMFile
Lucy::Store::RAMFileHandle
Lucy::Util::Debug
Lucy::Util::IndexFileNames
Lucy::Util::Json
Lucy::Util::MemoryPool
Lucy::Util::PriorityQueue
Lucy::Util::SortExternal
Lucy::Util::Stepper
Lucy::Util::StringHelper

It should still be possible to work with these classes by simply adding "use 
Lucy", but code like "use Lucy::Plan::Int32Type" would break. Additional 
workarounds are needed for "use Lucy::Private::Class qw(imp1 imp2)" or "use 
base qw(Lucy::Private::Class)".

Another option is to populate the %INC hash with fake entries for each class 
when loading Lucy.pm. This would allow to remove all other .pm files but keep 
"use Lucy::Private::Class" working.

Nick


Re: [lucy-dev] 0.6.1 release

Posted by Nick Wellnhofer <we...@aevum.de>.
On 24/11/2016 06:37, Marvin Humphrey wrote:
> The historical motivation behind all those manipulations was to improve the
> presentation on search.cpan.org, by ensuring that only the classes actually
> included in the public API showed up.  Having a bunch of non-public classes
> with blank or broken documentation cluttered things up.

This seems like a historical artifact then. We don't have any non-public 
classes implemented in Perl these days. There are a couple of empty .pm files 
for such classes, but these can be simply removed.

What I don't understand is the list of classes in Lucy::Redacted:

 
https://git1-us-west.apache.org/repos/asf?p=lucy.git;a=blob;f=perl/buildlib/Lucy/Redacted.pm;h=21abca8fb13e858487309f1e5d8401e16b945482;hb=HEAD

Most of these are completely gone. Some are non-public. For Lucy::Object::Obj, 
there's some POD explaining that the class was moved:

 
https://git1-us-west.apache.org/repos/asf?p=lucy.git;a=blob;f=perl/lib/Lucy/Object/Obj.pm;h=79532f2c9b88ddcf5fbd9b97a16eccc5c90a5408;hb=HEAD

But if we want to keep such notes around, it doesn't make much sense to try 
hide them from CPAN. (Note that the mechanism to hide them doesn't even work 
as explained in LUCY-313.)

I'll simply go ahead and

- remove _gen_pause_exclusion_list in Lucy::Build,
- remove Lucy::Redacted,
- remove .pm files for non-public classes,
- add a no_index entry in Build.PL for buildlib and test code.

This removes a bunch of code with seemingly no effect and cleans up the CPAN 
META files. The only danger I can see is breaking Perl code that still "use"s 
an obsolete class.

Another side effect is that the "provides" section will be removed from the 
CPAN META files. This breaks the version checks in our custom ACTION_distmeta. 
This is unfortunate, but our update_version script should be robust enough. Or 
are there other benefits from having a "provides" section?

 
http://search.cpan.org/~dagolden/CPAN-Meta-2.150010/lib/CPAN/Meta/Spec.pm#provides

All this data seems to be generated by the PAUSE indexer anyway, even if the 
section is missing.

Nick


Re: [lucy-dev] 0.6.1 release

Posted by Marvin Humphrey <ma...@rectangular.com>.
On Wed, Nov 23, 2016 at 9:00 AM, Nick Wellnhofer <we...@aevum.de> wrote:
> I'd like to release 0.6.1 with the following fixes:

+1

> In the meantime, I uploaded a couple of development releases to CPAN to fix
> failure reports from CPAN Testers. There's one Clownfish issue that is still
> unresolved:
>
>     https://issues.apache.org/jira/browse/CLOWNFISH-109
>
> I added some diagnostics, but unfortunately, I didn't get any more reports
> from the particular tester who encountered the errors.

I don't really have any better ideas about this one.

> On the Lucy side, I'd still like to address LUCY-313:
>
>     https://issues.apache.org/jira/browse/LUCY-313

The historical motivation behind all those manipulations was to improve the
presentation on search.cpan.org, by ensuring that only the classes actually
included in the public API showed up.  Having a bunch of non-public classes
with blank or broken documentation cluttered things up.

> My current plan is:
>
> - Ignore CLOWNFISH-109 for now.
> - Fix LUCY-313.
> - Upload another Lucy dev release to CPAN.
> - If all goes well, create an RC for 0.6.1.

Right on. :)

Marvin