Time for a release?

26 views
Skip to first unread message

Daniel Lindsley

unread,
Oct 27, 2013, 5:02:51 PM10/27/13
to django-ha...@googlegroups.com
Core,


It’s been awhile since the last release, so I’d like to roll a major one within the next week or so (v2.2.0). I haven’t seen many complaints about the Python 3 port I did, so either no one is using it or it’s alright enough. 

AFAIK, there’s only 1-2 blockers out there:

* Merging Honza’s ES branch - I’m trying to take care of this one within the next couple days. Honza’s pretty responsive & I’m guessing that there’s either a Py3 bug in ``elasticsearch`` or that Haystack is still making assumptions from ``pyelasticsearch``. Regardless, I think this is good & I’d like to get it in there.
* Django CBV support - From the discussion on the list a couple days back, it seemed like there was interest in getting that PR moved forward. Is this something we can happen for the release or should we push off? There’s an obvious strong sentiment about this one (both on core & in the community), so I guess it’d be a nice-to-have.

Are there any other blockers or things people would like to get in? There’s no deadline on this, so if we need to push out a week or so, that’s fine. It just feels like it’s time to get another release out there.

Beyond that, to get a release out, I’d like to start keeping release notes as part of the official docs. I’ll volunteer to take this one, since we have no prior art in Haystack & I have a good idea of what I’d like in them.

I know you’re all busy people, so I don’t want to push. I want to apologize for being relatively absent since adding many of you, though it’s been at least partially out of my control. Thank you all for doing a great job helping out, it’s really appreciated!


Daniel

bigjust

unread,
Oct 28, 2013, 11:57:57 AM10/28/13
to Daniel Lindsley, django-ha...@googlegroups.com

As far as the solr backend goes, spatial and content extraction doesn't
currently work. I would almost be ok with release without solr 4 spatial
until the next point release, but i think we should get content
extraction working, as we've already had a confirmation that a real user
is missing that feature already.

Also, Travis now runs our test suite, do you think we can get the
toastdriven's repository's hooks turned on for that?

I agree that the ES transition should be ready, although i think the
python3 problems on our end, according to some recent testing runs I've
done locally, and I believe most of that is simply unicode related.

I think we can reasonably target the next week or two for the next point
release.

-- justin

Daniel Lindsley

unread,
Oct 29, 2013, 2:14:55 AM10/29/13
to django-ha...@googlegroups.com
I’ve got Travis’ service hook setup (I think) so we should check that on the next commit/push. The soonest I can get to spatial/extraction/ES is toward the end of the week, so if someone else can get there sooner, that’d be great.


Daniel
--
You received this message because you are subscribed to the Google Groups "Haystack Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-haystack...@googlegroups.com.
To post to this group, send email to django-ha...@googlegroups.com.

Caratzas, Justin (CMG-Atlanta)

unread,
Jan 3, 2014, 3:41:58 PM1/3/14
to django-ha...@googlegroups.com
Team,

Thanks to Chris' work over the holidays, we've now hit the milestone that all tests are passing[1], and solr spatial appears to be working with solr4.  Anyone opposed to a 2.2.0 release early next week?

-- justin

[1] -- the one exception is the content extraction test, which has been traced to an issue in pysolr, and is fixed on pysolr's master.  We don't directly pull in pysolr, so it doesn't affect our release process.

From: django-ha...@googlegroups.com [django-ha...@googlegroups.com] on behalf of Daniel Lindsley [dan...@toastdriven.com]
Sent: Tuesday, October 29, 2013 2:14 AM
To: django-ha...@googlegroups.com
Subject: Re: [django-haystack-dev:26] Time for a release?

Chris Adams

unread,
Jan 3, 2014, 3:56:14 PM1/3/14
to Caratzas, Justin (CMG-Atlanta), django-ha...@googlegroups.com
+1 – there have been a bunch of nice fixes:


I took a first pass at collecting the more interesting commits into a release:


Chris

Honza Král

unread,
Jan 3, 2014, 5:47:56 PM1/3/14
to Chris Adams, Caratzas, Justin (CMG-Atlanta), django-ha...@googlegroups.com
Hi,

I'd like to ask you to wait a little bit, I should be able to go through all the ES tickets by next week so if we could get those fixes (or make sure none are required) into the release it would be nice.

I'd also like you to consider PR #921 for the next release - it's a breaking change (will require people to reindex and introduces some dependency on current identifier format) but one that I consider necessary. It will provide some performance speedups and, most importantly, will make haystack play nicer with elasticsearch leaving it as a viable option even for doing more advanced stuff - simply enable people to use haystack for indexing and simple search and drop down to the lower-level client to do the advanced queries and/or use other features like the percolator.

In the spirit of this approach I will also like to start working on an API to allow a standardized way to access the lower-level clients from the backends and maybe plug more advanced queries back into haystack (similar to what Django's orm does with .raw()) - that is currently the biggest issue ES users have with haystack. Does this make sense?

Thanks!

Honza Král
E-Mail: honza...@gmail.com
Phone:  +420 606 678585


--

Chris Adams

unread,
Jan 3, 2014, 6:21:22 PM1/3/14
to Honza Král, Caratzas, Justin (CMG-Atlanta), django-ha...@googlegroups.com
If you're actively working on those ES tickets, delaying seems quite reasonable - it'd be nice to close out that backlog.

I'm in favor of an API for better low-level client access. Awhile back I created https://github.com/toastdriven/django-haystack/issues/750 to track a related problem when I needed to start using Solr's field collapsing support, which completely changed the response format. I need to review that against the current tree but would like to simplify the process of extending the standard backends like this as well when you want to use native features but would like to reuse some of the queryset-like behaviour.

Chris
Reply all
Reply to author
Forward
0 new messages