Category: Updates

Server update, 2013-07-22

We’ve just finished deploying the second update to musicbrainz.org for July. Continuing the trend, this release is primarily bug fixes with a few new improvements. Notably, people should be happy to hear that the Cover Art Archive now supports PNGs and GIFs, ISRC editing has become easier, and the release and relationship editors should be a little bit more stable. Many thanks to Nicolás Tamargo along with the MusicBrainz team for their continued work on MusicBrainz. Here’s what’s changed:

Bug

  • [MBS-3132] – Problems with track artist credits when seeding the release editor
  • [MBS-5310] – Artist aliases should not be shown for work relations when doing a release lookup
  • [MBS-5409] – Internal server error when artist begin year is 0
  • [MBS-5637] – Regression: Recording merges can result in duplicate relationships
  • [MBS-6058] – Artist Subscriptions overview page is contradicting itself
  • [MBS-6194] – regression : drums release relationships were invisible as long as there was at least one recording drums relationship
  • [MBS-6235] – Internal server error when using date of birth without century in profile
  • [MBS-6273] – Country names are no longer shown in the sidebar or in edits
  • [MBS-6275] – Diffs no longer work for release dates
  • [MBS-6276] – Release dates are badly aligned in edits
  • [MBS-6280] – Registering an account ignores DB_READ_ONLY
  • [MBS-6282] – Uploading cover art ignores DB_READ_ONLY
  • [MBS-6283] – Voting on edits ignores DB_READ_ONLY
  • [MBS-6284] – Cancelling edits ignores DB_READ_ONLY
  • [MBS-6285] – Verifying an email address ignores DB_READ_ONLY
  • [MBS-6286] – Editing profile/preferences/password ignores DB_READ_ONLY
  • [MBS-6288] – Adding ISRCs ignores DB_READ_ONLY
  • [MBS-6289] – Editing CD stubs ignores DB_READ_ONLY
  • [MBS-6290] – Removing subscriptions ignores DB_READ_ONLY
  • [MBS-6354] – Possible to edit after unsetting email
  • [MBS-6360] – Internal server error when trying to authenticate via digest auth with non-ASCII username
  • [MBS-6369] – No link to area when editing an artist, a label or anything that has an area inline search
  • [MBS-6401] – Regression: Default release group cover art is not (always?) the original release
  • [MBS-6403] – Resetting password ignores DB_READ_ONLY
  • [MBS-6410] – Internal Server Error
  • [MBS-6413] – Areas’ releases tab should show "This area is not currently associated with any releases" if empty
  • [MBS-6417] – JSON API does not return disc number information for media
  • [MBS-6426] – ModBot unable to close old edit release edits that cleared both date and country
  • [MBS-6454] – Pressing enter when editing a relationship type does not submit the form
  • [MBS-6455] – Internal server error displaying edit relationship type edits
  • [MBS-6468] – Relationship type documentation pages are not linked in appropriate places
  • [MBS-6486] – ModBot no longer enters remove relationship edits when using "Split into separate artists"
  • [MBS-6498] – Internal server error displaying an historic set track lengths edit
  • [MBS-6531] – area/not_found.tt doesn’t exist
  • [MBS-6536] – OAuth token expiration ISE
  • [MBS-6569] – JSON file uploaded to the IA has the wrong file extensions for GIFs/PNGs
  • [MBS-6578] – ModBot is unable to close Edit::Area::Merge edits

Improvement

  • [MBS-2411] – Login page should be encrypted (SSL/TLS)
  • [MBS-4114] – Cover art archive: Support .gif
  • [MBS-4671] – Enter "Remove relationship" edits as the same editor instead of ModBot when splitting artists
  • [MBS-5868] – Move ISRC editing to the edit recording page
  • [MBS-6022] – Cover art archive: Support .png UI Changes
  • [MBS-6414] – Wikidata URL cleanup should also remove the "fragment" part of the URL
  • [MBS-6457] – Relationship editor deals confusingly with deprecated relationships
  • [MBS-6575] – Provide more debugging information if the release editor fails to create edits

The Git tag for this release is v-2013-07-22.

Server update, 2013-07-08

We’ve just finished deploying the latest version of MusicBrainz on our servers. This release is again primarily a bug fix release, but as always we’ve got a couple of improvements in added too. Thanks to Michael Wiencek, Nicolás Tamargo, nikki and the MusicBrainz team for all their work on this release! Here’s a list of what’s changed:

Bug

  • [MBS-5892] – Make wikidocs links always go to the server the user is on
  • [MBS-5941] – Using the link to http://musicbrainz.org from beta.mb after starting to use the beta site redirects to beta.mb again
  • [MBS-6020] – Work types in the relationship editor still don’t sort alphabetically
  • [MBS-6272] – Countries are no longer linked in the release sidebar
  • [MBS-6325] – Moving a release with a release date into an empty release group does not provide it with a date (sorting doesn’t work)
  • [MBS-6327] – Development servers ask users to change passwords when logging in
  • [MBS-6331] – Internal server error entering an existing ISO code
  • [MBS-6384] – Internal server error looking up a disc ID in the JSON webservice
  • [MBS-6404] – Regression: it is impossible to have a track without "track #" field empty (despite edit doing just that passes without problem)
  • [MBS-6440] – Opening filter fails due to syntax error
  • [MBS-6485] – Blocking of /ws/1 URLs should be done in MusicBrainz-Server, not nginx config
  • [MBS-6491] – Editing an artist area should not be an auto-edit
  • [MBS-6501] – Internal Server Error: "Wide character in subroutine entry" trying to create an account with Unicode characters in the username or password
  • [MBS-6504] – Digest authentication is broken for new accounts until the password is changed
  • [MBS-6519] – Recording index page column span is incorrect
  • [MBS-6524] – Work type and lyrics language ordered differently for editing and display
  • [MBS-6548] – ModBot is unable to close Edit::Relationship::Delete edits

Improvement

  • [MBS-5487] – Edit search : Add the relationship type information to "remove relationship" edits
  • [MBS-5835] – Report of recordings with tracks which vary a lot in length
  • [MBS-6132] – Show filename in Add/Edit cover art edits as in removals
  • [MBS-6226] – Use new page version in the wikidocs edit page form
  • [MBS-6258] – Add accept/reject buttons to the edit search results pages on test servers
  • [MBS-6350] – Merge release events where dates are equal but release country in one or more instances is unknown
  • [MBS-6499] – Kill the nag

Task

  • [MBS-6432] – lyricstatus.com→decoda.com
  • [MBS-6526] – http://www.myspace.com/COUCOU → https://myspace.com/COUCOU
  • [MBS-6527] – Update SoundCloud URL cleanup to use https

The Git tag for this release is v-2013-07-08.

Server Update, 2013-06-25

We’ve just finished pushing out another version of MusicBrainz. Sorry that we’re a day behind on this one, yesterday we had a few tests that needed fixing before we could release. This release is mostly bug fixes and small improvements, and should solve problems with the “remember me” login feature working incorrectly. This upgrade might have lost a few remember me tokens, but if you are still seeing problems after a few days of the site, please leave a comment on MBS-6471.

Many thanks to Lukáš Lalinský, Michael Wiencek, Nicolás Tamargo and the rest of the MusicBrainz team for their work on this release. Here’s what changed:

Bug

  • [MBS-3427] – "Internal Server Error" submitting CD Stubs with invalid data
  • [MBS-5524] – Edit relationship type edits are missing information for identifying the relationship type
  • [MBS-5903] – JSON webservice doesn’t return release-list in collection query
  • [MBS-5958] – Release editor did something very very wrong
  • [MBS-6027] – JSON webservice returns asin: null for releases with ASINs
  • [MBS-6073] – Inaccurate range of credits when grouped at the bottom of a release page
  • [MBS-6101] – Redis should only be required if sessions are used
  • [MBS-6206] – Soundtrack Collector URLs should not be possible at the Release level
  • [MBS-6244] – Private data dump contains bcrypt column and can’t be imported
  • [MBS-6261] – "Date unknown" is inconsistent with our handling of unknown values elsewhere
  • [MBS-6296] – Area alias links are shown for non-location-editors
  • [MBS-6315] – Recordings tab of the RE showing lots of [removed]
  • [MBS-6349] – Artist credits display wrong on add release edit
  • [MBS-6364] – "Possibly duplicate artists" report doesn’t show any results
  • [MBS-6374] – Release editor seeding is broken
  • [MBS-6383] – Can’t add search hint to area
  • [MBS-6416] – release editor loses track identifiers when editing a medium.
  • [MBS-6467] – "you may add a new label" in area search
  • [MBS-6471] – "Keep me logged in" is broken

Improvement

  • [MBS-2782] – "Edit medium" edit type > Don’t show pointless artists credits changes (e.g. when only join phrase has been changed)
  • [MBS-2848] – New "Add medium" artist credits section is cluttered and hard to parse
  • [MBS-3663] – "No" votes should allow time for the original editor to respond
  • [MBS-4652] – Add a link to How To under Documentation
  • [MBS-5911] – Display source for non-CAA cover art
  • [MBS-6205] – Clean up Soundtrack Collector URLs
  • [MBS-6207] – Check formatting for Soundtrack Collector URLs
  • [MBS-6259] – Bring back date/country columns in tables
  • [MBS-6352] – ExportAllTables::check_tables_completeness should be updated and used
  • [MBS-6363] – Update Twitter URL cleanup to use https

The Git tag for this release is v-2013-06-25.

Search server update: June 13

On 13th June we updated the search servers once more. Thanks for fixing bugs and adding Area support, Paul!

Release Notes – MusicBrainz Search Server – Version 2013-06-13

Bug

  • [SEARCH-297] – Webservice Json output for aliases when searching is inconsistent with output when doing a lookup
  • [SEARCH-302] – search server json output use singular for a list of release-groups.

Improvement

  • [SEARCH-292] – Include area info in the indexed search artist and label results
  • [SEARCH-299] – Ouput TrackIds

New Feature

  • [SEARCH-301] – Search for Area by ISO 3166 code

Task

  • [SEARCH-273] – Support for multiple country/release events on release as as part of schema changes
  • [SEARCH-286] – Add areas to the indexed search

Upcoming feature: contested edit extension

The next release (a week from Monday) will include a useful new feature: extending the expiration of edits that receive ‘No’ votes! I’d like to take a bit to explain how it’ll work.

The problem

Especially since the amount of time edits stay open was reduced to 7 days, but also before, several problematic situations could arise when edits were contested:

  • If voters cast ‘No’ votes shortly before the expiration of the edit, the original editor may not have time to respond to the concerns before the edit closes. As a result, it’s generally been considered bad etiquette to cast ‘No’ votes right before an edit expires unless the edit is particularly destructive.
  • In a somewhat related case, sometimes an edit can get many ‘No’ votes in short succession. Since 3 unanimous ‘No’ votes will close an edit, the period between the first vote cast and the edit being closed can be as short as an hour, which is certainly not enough time for the original editor or other voters to respond.
  • It’s also occasionally possible for edits to be put at risk of failing without an email being sent. Specifically, the current code only sends an email on the very first ‘No’ vote. Therefore, if a voter votes ‘No’ early in the voting period and later changes their vote, a second voter later voting ‘No’ would not result in an email being sent. However, a tied vote or a majority of ‘No’ votes will result in an edit being closed, so even a lone vote can tip the balance.

The solution

In light of all of these problems, the next release will work differently to give editors time to respond to votes against their edits.

In short: editors will always have at least 72 hours (three days) to respond after the first vote against their edits.

More specifically, and more technically:

To address the third point above, the emails for ‘No’ votes will now be sent whenever the count of ‘No’ votes goes from 0 to 1. That is: if two people vote ‘No’ with neither changing their vote in-between, only one email will be sent. But, in a case like the one described above, where an early ‘No’ vote is superseded and the total count goes back to 0, a subsequent ‘No’ vote will send a new email.

To address the second point above, ModBot will not reject an edit before its expiration time due to three unanimous ‘No’ votes unless 72 hours have passed since the earliest ‘No’ vote (that is, the vote which resulted in an email being sent). If the expiration time passes or an edit has three unanimous ‘No’ votes after 72 hours, the edit will be closed as usual.

Finally, to address the first point above, when new ‘No’ votes are cast close to an edit’s expiration time, the edit’s expiration time will be extended to allow 72 hours for response. This extension will, once again, only happen when the total count of ‘No’ votes goes from 0 to 1 – so only when an edit becomes contested and previously was not.

In total, these changes should hopefully ensure that editors are better informed about edits that are in danger of being voted down, and given sufficient time to respond to voter concerns.

In summary

First of all, this change will be fully live on Monday, June 24th. Before then, votes cast on the beta server may result in a small number of edits having their expiration times extended, but it won’t happen on the main server or for the majority of edits.

While editing: Rest assured you’ll be informed and given time to fix problems with your edits!

While voting: Don’t worry too much about casting ‘No’ votes when edits need improvement. Certainly be ready to supersede your votes if things do get fixed up, but if you find an edit in need of fixing just before it closes, or which already has a bunch of recent ‘No’ votes, don’t hold back or vote differently to give the original editor time to respond. This should take care of that for you!

Happy editing!

Server Update, 2013-06-10

Another week, another release! This release is mostly bug fixes, but I’m sure a lot of people will be happy to notice that we have finally resolved MBS-357. That’s right – we no longer have a single clear text password in the MusicBrainz database. We’re sorry that it took so long, but at least it’s finally been done! Other than that, this release mostly builds on top of the new schema change features, and provides bug fixes for things that have regressed.

Many thanks to Michael Wiencek, Nicolás Tamargo and the MusicBrainz team for their work in this release. Here’s what’s changed:

Bug

  • [MBS-6007] – JSON release webservice doesn’t include works
  • [MBS-6179] – Sorting a collection by catalog number sorts ‘8BP117’, ‘8BP126’ and ‘8BP127’ in the wrong order
  • [MBS-6260] – Dates and countries are displayed inconsistently
  • [MBS-6263] – Adding an area without ISO 3166 codes shows blank values in edits
  • [MBS-6264] – Languages/Scripts statistics have an empty "Last updated field"
  • [MBS-6297] – Can’t create relationships from areas to other entities from the area page, but only from the other entities’ page
  • [MBS-6325] – Moving a release with a release date into an empty release group does not provide it with a date (sorting doesn’t work)
  • [MBS-6326] – ModBot is unable to close some edits as they still use ‘country_id’
  • [MBS-6334] – Release editor: loses join phrases and artist credits when switching to tracklist tab
  • [MBS-6355] – 502 displaying relationships for prolific artist
  • [MBS-6357] – Track/medium tables have indexes/constraints with bad names
  • [MBS-6370] – Beta: Inline search can load duplicate results
  • [MBS-6377] – Track ACs appear changed but the edit isn’t submitted
  • [MBS-6385] – Strange results when pasting an area URL in the inline search
  • [MBS-6409] – ModBot leaves translated edit notes
  • [MBS-6441] – Release (date, country) are blank when displaying a disc ID
  • [MBS-6443] – Ascending and descending sorting of releases in a collection results in the same order

Improvement

  • [MBS-357] – Don’t store passwords in clear text
  • [MBS-4962] – Slave servers should cache heavily due to hourly update process
  • [MBS-6203] – Only allow recognised URLs for relationship types which are for specific sites
  • [MBS-6233] – Ensure SecondHandSongs links are added at the right level
  • [MBS-6300] – Link to countries in country statistics
  • [MBS-6301] – Consider linking to areas {artist,release,label} list in country statistics
  • [MBS-6347] – Show parents somehow for underlying areas
  • [MBS-6358] – Add basic area stats display
  • [MBS-6362] – Improve how release data is displayed in Google searches
  • [MBS-6371] – Extend Wikipedia and Wikidata autoselect to areas

New Feature

  • [MBS-6269] – Expose track identifiers in the webservice
  • [MBS-6270] – Expose track identifiers on the website

The Git tag for this release is v-2013-06-10.

Server update, 2013-05-28

Now that the fires around the last schema upgrade seem to be dying down to a much more manageable level, we’ve just put out the next version of MusicBrainz server. As you might already expect, this release is mostly a bug fix release. Thanks to Lukáš Lalinský, Michael Wiencek, Nicolás Tamargo and the rest of the MusicBrainz team for their work on this release. Here’s what’s changed:

Bug

  • [MBS-3059] – Using "Submit votes & edit notes" added edit note to all edits
  • [MBS-6158] – Reset password form claims the user/email address does not exist
  • [MBS-6172] – Lost password claims to work when user has no email
  • [MBS-6209] – Direct search for work doesn’t check aliases
  • [MBS-6230] – Internal server error removing a relationship in the relationship editor
  • [MBS-6271] – Internal server error trying to set track lengths
  • [MBS-6274] – Capitalisation of "release events" in sidebar and edits is inconsistent
  • [MBS-6299] – "License" header in release sidebars is displayed even if the following list is empty
  • [MBS-6302] – Country column empty in search results page
  • [MBS-6304] – Table on Attach CD TOC page broken (too many columns)
  • [MBS-6305] – Regression: Release dates are no longer optional
  • [MBS-6318] – Search hint alias for areas require a sortname when adding
  • [MBS-6319] – Internal server error editing an area alias
  • [MBS-6329] – REGRESSION. no more dates in collection pages
  • [MBS-6335] – Regression: Tracklists not shown when merging releases
  • [MBS-6341] – Area alias aren’t found by direct search unless they match an area name

Improvement

  • [MBS-3083] – Do not use placeholder text for artist credit names
  • [MBS-5603] – Edit relationships page should show disambiguation comments
  • [MBS-6198] – Deleted Editor Stats
  • [MBS-6213] – Permit ISRCs starting with TC
  • [MBS-6219] – Stop using two edit types and two places in the UI for the "change release group" functionality
  • [MBS-6222] – Update FeaturingRecordings report
  • [MBS-6223] – Display language and script in the right order on release edits
  • [MBS-6294] – Release events are weirdly indented on release pages
  • [MBS-6340] – Redirect to direct search for indexed area searches as long as the latter are not actually available
  • [MBS-6348] – Display the type of area on inline search

New Feature

  • [MBS-6018] – Add /oauth2/tokeninfo and /oauth2/userinfo handlers for 3rd party login

Task

  • [MBS-6229] – Add autoselect, sidebar links and pretty URLs for Wikidata

The Git tag for this release is v-2013-05-28.

Schema 17/18 upgrade instructions

We’ve just completed our extra schema upgrade. The full instructions for upgrade follow:

Schema 16 to schema 17 upgrade

If you already ran the migration that was announced May 15th, or if you imported a data dump from May 15th or later, skip to the next section.

  1. Run replication with carton exec -Ilib -- ./admin/replication/LoadReplicationChanges until it cannot apply any packets in schema 16.
  2. Take down the web server running MusicBrainz, if you’re running a web server.
  3. Turn off cron jobs if you are automatically updating the database via cron jobs.
  4. Make sure your REPLICATION_TYPE setting is RT_SLAVE in lib/DBDefs.pm
  5. Switch to the new code with git fetch origin followed by git checkout schema-16-to-17
  6. Run carton install --deployment to install any new perl modules.
  7. Run carton exec -Ilib -- ./upgrade.sh from the top of the source directory.
  8. Set DB_SCHEMA_SEQUENCE to 17 in lib/DBDefs.pm
  9. Turn cron jobs back on, if needed.
  10. Restart the MusicBrainz web server, if needed.

Schema 17 to schema 18 upgrade

  1. Run replication with carton exec -Ilib -- ./admin/replication/LoadReplicationChanges until it cannot apply any packets in schema 17.
  2. Take down the web server running MusicBrainz, if you’re running a web server.
  3. Turn off cron jobs if you are automatically updating the database via cron jobs.
  4. Make sure your REPLICATION_TYPE setting is RT_SLAVE in lib/DBDefs.pm
  5. Switch to the new code with git fetch origin followed by git checkout v-2013-05-24
  6. Run carton exec -Ilib -- ./upgrade.sh from the top of the source directory.
  7. Set DB_SCHEMA_SEQUENCE to 18 in lib/DBDefs.pm
  8. Turn cron jobs back on, if needed.
  9. Restart the MusicBrainz web server, if needed. EDIT: also restart memcached here, see http://tickets.musicbrainz.org/browse/MBS-6376

Note that the tags to check out for the two migrations are different.

Changes

For the list of changes in schema 17, see the former blog post. The changes for schema 18 are:

  1. Fix the track table corruption that the schema 16-17 upgrade created, by importing a copy of the ‘track’ table from the production database.
  2. Fix some indexes and constraints that should not be on slaves or which had bad names starting with ‘medium2013’ or ‘track2013’
  3. Create a missing index on medium.release that dramatically improves performance.
  4. Fix the ref_count column of the artist_credit table, which was not updated properly at the schema 16-17 upgrade.

Urgent schema update required

On Friday 24 May, 2013 at 15:00UTC we’re going to make an urgent schema update to fix a problem that occurred during our schema change last week. Please read this whole blog post carefully!

This update will not make any changes to the schema, but it will fix some data issues that have appeared on slave servers.

We apologize profusely for these problems — we’re working hard to rectify this problem and we’re going to improve our processes going forward to ensure that future releases will not encounter these problems.

What went wrong

Due to a misunderstanding of our database system, the ‘track’ table will be corrupted on the majority of replicated slave databases after the schema 17 migration. Specifically, depending on the internal choices of a given postgresql installation’s query planner and other system details, any particular server can end up with a variety of incompatible permutations of the track table, where ‘id’/’gid’ pairs will generally point to the incorrect track data. Unfortunately, this problem is compounded by replication, which is based on the ‘id’ column. Therefore, replication packets since the schema change are likely to have deleted and modified the incorrect rows of the ‘track’ table on slaves.

How are we fixing it

In order to ensure that no slaves continue to replicate incompatible changes, we are incrementing the schema number again to 18, which will force operators of slave servers to intervene appropriately. To ensure that slaves have a correct version of the ‘track’ table, we are providing an upgrade script that will download an exported snapshot of the production server’s ‘track’ table at a known point and import it, as well as correct some smaller issues. By importing this snapshot, slave servers will be reset to a correct version of this table and replication can continue.

Specific step by step instructions on running this upgrade will be in a separate blog post. Watch this space!

What problems may have arisen

  1. In the unlikely case an external program directly references track row ID numbers, or if it uses the newly-added track MBID field (the ‘gid’ column), these will not be correct if they were taken from any server but the production server. If an application stores either of these identifiers in any way, that data should be rebuilt.
  2. Due to the compounding problems from replication, some tracklists will have incorrect information — missing tracks, misnumbered tracks, links to the wrong recordings, wrong durations, and/or wrong track artist credits. Information of this sort that was derived from replicated slaves during the affected period should be regenerated after upgrading.

FAQ about this update

Q: We don’t use the track table, we use recordings. Am I affected?
A: You are not affected if you use recordings directly, i.e., looking up recording information by a stored recording MBID, except if you use track information linked to those recordings (for example, if you create a list of releases a given recording appears on). Since the link between the recording and the release tables is via the ‘track’ table, anything that connects these two entities is likely to be affected.

Q: How can I tell if any of the tracklists I am using are affected?
A: Due to the random permutation issue, it’s not completely possible to be 100% sure. However, it’s possible to know of tracklists that definitely have problems by two means: track counts, and sequence issues. The former can be tested with a fairly simple query: “

SELECT medium.id, medium.track_count, count(track.id) as track_track_count,
     medium.track_count  count(track.id) AS counts_differ
FROM medium join track on track.medium = medium.id
GROUP BY medium.id, medium.track_count
HAVING count(track.id)  medium.track_count;

Any medium that appears in that query has been affected and its tracklist should not be trusted (select ‘medium.release’ to get release IDs, if that’s your jam). Sequence issues are a more complex query:

SELECT distinct m.id FROM
  (SELECT DISTINCT medium.* FROM
    ( SELECT track.medium, min(track.position) AS first_track, max(track.position)
      AS last_track, count(track.position) AS track_count, sum(track.position)
      AS track_pos_acc
      FROM track
      GROUP BY track.medium) s
    JOIN medium ON medium.id = s.medium
    WHERE first_track != 1 OR last_track != s.track_count OR
        (s.track_count * (1 + s.track_count)) / 2  track_pos_acc
    ) m

(note: if you only get 10 rows for this query, you’re fine — they’re these ten, which are known problems)

For more safety, don’t trust anything in the track table that’s been updated since the schema change:

SELECT distinct medium
FROM track
WHERE last_updated > ‘2013-05-15’

If it’s possible in your application, it’s probably best to throw out any updates to tracklists since 2013-05-15.

Again, we’re sorry for the trouble this update may have caused you!

Search server regressions fixed

Yesterday we pushed out a new version of our search servers to fix some regressions introduced last week. Thanks to Paul Taylor for fixing these bugs so quickly.

Release Notes – MusicBrainz Search Server – Version 2013-20-05

Bug

  • [SEARCH-290] – REGRESSION WS2 RECORDING query returns cropped artist-credit
  • [SEARCH-294] – REGRESSION:Search results no longer include medium-list count attribute
  • [SEARCH-298] – REGRESSION:ws/1 release search seems broken

Improvement

  • [SEARCH-296] – Update README to point to up-to-date mmd-schema repository