0.13.0.0 release

[bitemyapp]

All the milestones are checked off, lets do a roll call for this to go to Hackage?

/cc @bermanjosh @MichaelXavier @MHova

[MHova]

👍 I have no objections.

Is there a place where I can see the milestone checklist? I poked around a bit and couldn't find it.

[bitemyapp]

@MHova click the milestone on the right-hand side

[bitemyapp]

You'll get a menu of open and closed issues tagged with that milestone

[bitemyapp]

Basically, everything but cutting the release is done, so this is an opportunity to speak up if you have something that should get in before release, otherwise I'll cut a release.

I'm trying to be extra careful with this because this is the multi-module release.

[MHova]

Ah I missed the part where I have to switch to the closed issues...

Looks good to me!

[MichaelXavier]

Let it rip!

[bermanjosh]

Works for me!

[bermanjosh]

Wait - should we update the docs on the front-page?

[bitemyapp]

@bermanjosh yep

[bitemyapp]

I've actually wanted to change that stuff into an example/ dir that gets compiled with the rest of the repository but I hadn't done it yet.

[wraithm]

Just out of curiosity, why are there no Seminearring instances in the ElasticSearch version 5 work? @bermanjosh Great work by the way, I've been testing the V5 modules, and everything works well so far.

[bermanjosh]

@wraithm No reason beyond the fact that filters are gone. I don't really understand the class; it seems to be half a Boolean.

[bitemyapp]

@bermanjosh This is disconcerting. I checked the Elasticsearch documentation and they still have separate query and filter contexts in which queries and filters can be used, they just don't reify them into separate sub-trees of the JSON document.

Do the types in V5/Types.hs permit the construction of an invalid Elasticsearch query as a result of this merge?

[bitemyapp]

As for Seminearring, there is still conjunction, disjunction, and identity in the query structure so anything that permits a valid instance should have one.

The point of Seminearring was to permit generic conj/disj/id for booleanish queries or filters without having to care about what the type too much. They had the faculty relatively centralized in V1 so it didn't matter much but I'm not sure how well this holds for V5.

[bermanjosh]

@bitemyapp As I understand the new ES5 types, all filters are now queries, and all queries are now valid to be treated as (i.e. run in the context of) a filter.

To match that, I replaced filters with wrapped queries.

Do you have an example of the type of invalid query this new representation opens up?

As to Seminearring - based on this new structure, I guess we could say:

• conjunction of two queries is a bool / must query
• disjunction of two queries is a bool / should query
• negation of a query is a bool / must_not query

The question is, should we try to leverage an existing Class, such as Boolean from cond. Someone at my office pointed out to me that it might allow for some application-level optimizations of queries by getting to normal form before getting to Elastic (though I haven't thought it all the way through, and I'm not sure how we'd test that they're actually equivalent).

[phadej]

Seems it's out but changelog.md misses an entry?

[phadej]

Also there aren't tags for any 0.12.x neither 0.13.0.0 releases.