Given the moving state of issues, this is a meta issue to narrow down the (few) fixes needed before I think we should roll the 6.x-1.3 release. Obviously, general testing and poking at that branch code would be great too.

Here are the issues I see that seem like they ought to be settled before the next release. These are generally rather small in terms of line of code and most just need to be ported or tested:

#899590: CCK facet definitions needs to expand its role and have a 'facets' param.
#840358: Error searching Taxonomies
#864146: When moving fq to q.alt, we should parenthesize each fq
#896324: module_invoke() called too late
#891962: Solr_Base_Query->parse_filters() causes filters to disappear when using or search on taxonomy id's
#955524: Pager does not respect params from modify_query hook
#882638: Clean the text inside indexed tags
#933066: Triggers Node Access Rebuild even if no module implements node_grants
#885950: parse_filters() causes any manually added filters to be lost
#903802: BLOCK_CACHE_PER_PAGE conflicts with theme_apachesolr_facet_list

and maybe:
#871440: Solr taxonomy page displays search form and blocks when the user has no access to the seach
#1084332: Drush command to get PHP client can't run

Comments

damienmckenna’s picture

damienmckenna
Location TN, USA
commented

Subscribe.

jpmckinney’s picture

jpmckinney commented

For 6.x-2.x I would like people to review my patches at:

#509982: Is our use of menu_alter incompatible with fallback to core search?
#614644: Forms attached to Apachesolr search results won't work
#783366: Synchronize apachesolr_search_browse with apachesolr_search_execute
#920880: facet_block_callback not propagated

apachesolr_commentsearch related:

#675262: [apachesolr_commentsearch] HTML entities erroneously generated for author names
#1031612: [apachesolr_commentsearch] Incompatibility with apachesolr_nodeaccess (haven't reviewed this myself)

apachesolr_date related:

#920880: facet_block_callback not propagated

damienmckenna’s picture

damienmckenna
Location TN, USA
commented

@jpmckinney: I believe the intent is to abandon v6.x-2.x, so I'm not sure if those will get any attention? Do those problems exist in v6.x-1.x?

jpmckinney’s picture

jpmckinney commented

The intent is to make one more release of 6.x-2.x, and then freeze it. Almost any bug in 6.x-2.x exists in 7.x, and many exist in 6.x-1.x too. It would be imprudent to ignore an issue just because it's tagged 6.x-2.x. I've been going through the 2.x queue and either retagging issues 1.x or 7.x or closing them. The two issues I've linked to in #2, however, are 6.x-2.x only. Given the massive number of issues I've closed, I'd appreciate it anyone could review those two.

jpmckinney’s picture

jpmckinney commented

Indeed, it is important to note that 6.x-2.x was the base of 7.x-1.x and (I think) will be the base of 6.x-3.x. Its experimental features may be abandoned, but as a branch it is the basis of all current work.

pwolanin’s picture

pwolanin commented

Yes, James point is #5 I wanted to makes also. Fixes is 6.x-2.x are likely to benefit 6.x-3.x or 7.x-1.x.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented

We're getting awfully meta here and going on a serious tangent, but if the 6.x-2.x is not being abandoned as it currently stands, shouldn't we instead:

  • Demote 6.x-1.x,
  • Stabilize & finish 6.x-2.x,
  • Stabilize & finish 7.x-1.x,
  • Branch 6.x-2.x to make 6.x-3.x and backport the schema changes?

The confusing part is the separation between 6.x-2.x and 7.x-1.x when the latter is supposed to be schema-incompatible with the former. Maybe it'd help if there were issues similar to this for 6.x-2.x and 7.x-1.x it'd help clarify and we wouldn't be adding 6.x-2.x issues to a 6.x-1.x roadmap?

pwolanin’s picture

pwolanin commented

6.x-2.x will be abandoned after the next release, but it will substantially be the starting point for 6.x-3.x. In other words, 6.x-3.x will essentially be the continuation of 6.x-2.x in terms of code history, but we are going to break so many APIs and change the schema that renaming it will help prevent confusion by end users. Hence, if we don't fix these bugs in 6.x-2.x now, we will likely be fixing them in 6.x-3.x later.

6.x-2.x was essentially Robert's testbed for new features, and he does not have time to maintain it, so I would like to make it clear to end users that it's EOL.

jpmckinney’s picture

jpmckinney commented

Yes, agreed. I posted 2.x issues here, because I'm nearly done closing all the 1.x issues, and I don't particularly like the proliferation of roadmap issues.

jpmckinney’s picture

jpmckinney commented

Btw, how long does Drupal cache project pages? There are only 208 issues now (58 fixed), not 277 (and 71 bugs, 26 fixed).

pwolanin’s picture

pwolanin commented

There's an open bug - it's caching for a week+ by mistake. #1077880: Block cache of issue counts on project pages is not invalidated when it should be

Side note - we should decide on a coherent naming system for schema/solrconfig files.

I suggest this for the next set of releases:

6.x-1.3: drupal-1.3

6.x-2.0-beta4: drupal-2.0-beta4

7.x-1.0-beta4, 6.x-3.x-dev: drupal-3.0-beta4

essentially 7.x we can declare is the 3rd branch in terms of config. I'd suggest we then have the 7.x-1.x and 6.x-3.x config names follow the name of the last 7.x release where the config was changed.

jpmckinney’s picture

jpmckinney commented

First-post has been updated with some of my suggestions.

Maybe:

#494182: apachesolr and core search treat Drupal fields (Field API, CCK) differently

For 1.4:

#985484: Core Search Indexer should be turned off automatically
#881760: account for http://drupal.org/node/345591
#594068: Deleting of taxonomy terms doesn't trigger index update

pwolanin’s picture

pwolanin commented

#594068 is non-trivial - so 1.3+ unless someone's driven to roll the patch.

#881760 is low priority, let's punt for after the release.

pwolanin’s picture

pwolanin commented
Status: Active » Needs review

So, I think all the issues we listed are committed to 6.x-1.x. Help in testing appreciated so we can roll the release with confidence.

jpmckinney’s picture

jpmckinney commented

Cool. Once released we can have another look at the issues mentioned in #12.

pwolanin’s picture

pwolanin commented

Seems like all the issues are fixed? the only one that's come up (minor) is:

#1130816: Spellchecker is rebuilt, when disabling spell check

jpmckinney’s picture

jpmckinney commented

Yes, we should probably fix that one. Before closing this issue we should create another one maybe for 1.4 issues (see #12).

pwolanin’s picture

pwolanin commented

I don't think the spellcheck one is critical - I'm going to release 1.3 unless there is any blocking bug you know of? And good idea to make a 1.4 meta-issue - we should have somewhat faster releases.

jpmckinney’s picture

jpmckinney commented

Nothing blocking. I committed the trivial #920482: $info_split['date'] template variable should contain changed, not created, date.

I would release beta4 of 6.x-2.x if not for the spectres of #998936: AND facets are not working/filtering? and #920892: Taxonomy OR facets do not work correctly

pwolanin’s picture

pwolanin commented
Status: Needs review » Fixed

release is rolling at: http://drupal.org/node/1135760

#1135764: roadmap for 6.x-1.6 release

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.