New release editor

For anyone who wishes to take a look at our new release editor, its now live on . Use your normal MusicBrainz account credentials to log in.

Click on this link to view an example release. There are still many things that are missing from this release editor and we need to wait for Warp to add more of the JavaScript portions to make it work right, but you should be able top get the right idea.

Thanks for your hard work on this Warp!

Where is NGS Beta 2?

I have some good news and some bad news. The bad news? NGS Beta 2 will be delayed by 4 weeks until June 21st. The good news? Read on!

The main reason why we’re having to slip the release is that we’ve finally found a UX design volunteer (Alisa Lemberg aka Aleeeza) who has been working with us to design a release editor that works well for the broad range of users we have. We had to go back quite a few steps in our previous work to come up with a sane release editor. Having a good user experience for one of the most critical pieces of MusicBrainz was more important to us than keeping our beta 2 schedule. In the nick of time for our deadline the new release editor will be available for public input as soon as Ollie (slacker!) is done updating the test server. Expect another post tomorrow.

The second reason that we’re behind is that we decided to make some really important fixes to the new Web Service. We’re going to ensure that the vast number of releases credited to Johann Sebastian Bach do not execute a denial of service attack on our servers (this is part the dreaded JSB problem). Warp has written a new specification for the new Web Service that illustrates our new approach. Unfortunately Beta 2 will not include the new browsing features discussed, but the other aspects will be adapted as per spec for beta 2.

Third, Ollie will shoot to finish all NGS edits (including migrating old edits) for the beta 2 release. This will make beta 2 complete with all of the most important features!

We’ve also agreed to add one more beta release (called Release Candidate 1) before we release NGS in order to give more exposure to NGS as we get closer to finishing.

Finally, we’re considering delaying a number of non-critical features to the releases beyond NGS. The dashboard, timeline, statistics and auto-editor elections are not critical for us delivering NGS. But, the development of NGS has dragged on long enough that we really ought to finish as soon as possible and that may mean delaying these features for a little while. (we can do auto editor elections by hand on a mailing list if need be). We’re not dropping these features — we’re simply delaying them for a few weeks past the NGS release (and perhaps a hot bug fix release immediately post NGS).

What do you think about us dropping non-critical features in exchange for delivering NGS sooner? Tell us about it in the comments!

NGS Beta 2: May 24th 2010

After much scheduling and getting our ducks in a row, we’re pleased to announce the final beta release of NGS on May 24th! This is one year after our last release, so this date is a little bitter/sweet for us. I had hoped to get this release out before then, but the team is making sure we’re getting this release right, and there are a ton of difficult things to get right.

And the tentative release date for NGS is going to be in July. No promises on a firm date yet.

Testing the NGS live data feed

If anyone would like to test out the NGS replication, which I’ve setup from the test server, follow these instructions:

  • Download and install the mb_server source code from SVN trunk. Follow these instructions.
  • Set your server type in to RT_SLAVE
  • Download and import this dataset.
  • Insert this required row into the database, using our psql program:
    cd /admin
    ./psql READWRITE
    insert into replication_control values (1, 12, 36169, '2010-01-23 00:00:02.604674+00');
  • Now run admin/replication/LoadReplicationChanges a few minutes after the hour to keep up to date with the data on the test server. Please note that this system may not be stable yet and that we will occaisionally load new data on our test server, which will require you to reload the data on your server.

Good luck!

Announcing NGS Beta 1!

After many years of discussion, planning and hard work, we’ve finally reached the much anticipated Next Generation Schema Beta 1 release!

For all the information on this release, please take a look at our release notes. Then head over to the test server and play with it!

Most important of all, please note that we are using Jira to keep track of bug for the MusicBrainz server now. Please do not enter bugs for Beta 1 into the old (trac) bug tracker!

Many thanks to the countless people who have helped make NGS a reality!

NGS Beta 1 is coming: Monday January 18

I’m pleased to announce that we’re almost ready to release beta 1 of the much anticipated Next Generation Schema. All of the important core functions are complete and we’ve even done a first round of sanity checking to make sure what what we release will be useful. We won’t have all of the features for NGS done — there will be some things that we simply won’t have finished by then.

But, this release is important since we feel that we want the community to help us take a look at NGS and help us flush out problems before we polish NGS for release.

We’ll have loads of more details and even some documentation for you by next monday. Stay tuned!

Web service users: What do you think of our current URL structure?

I’m about to finish writing the web service (version 1 & 2) for NGS, based on the work that Lukas started a few months ago. The NGS web service currently does not have a compete means of tweaking how much XML is returned for a given resource. Lukas wondered if we should keep our existing approach or start using a new approach that (and others) use.

Compare our current approach:

/ws/1/release-group/052c7adb-5e2d-3cf3-b303-6c2a7d3e5b1c/?type=xml&inc=releases (docs)

to the approach:

/2.0/?method=album.getinfo&artist=Cher&album=Believe (docs)

Should we keep our current resource focused URL structure or move to a method centric approach in our v2?

If you’re a fan of the old skool structure, please leave a comment and tell us what could be improved. What do you like about the web service? What do you hate?

For some background — as of the NGS release we will be making a lot of changes:

  • the old RDF web service will no longer work.
  • The old v1 XML interface will continue to work, but not optimally since we will be shoe-horning the spiffy new NGS XML into the old skool v1 XML. Concepts like artist-credits and works will not be available in the v1 compatibility interface.
  • The new v2 XML interface will expose all the NGS goodies like artist-credits and works.

Getting ready for our Next Generation Schema!

After many years of planning, anticipating and gathering resources, we’re finally tangibly close to our Next Generation Schema (NGS).

This blog post is intended as an official notification to everyone in our community and our customers who are using MusicBrainz services right now. Our next generation schema is drastic evolution for MusicBrainz — we’ve included many of the features that our customers and our community has asked for over the past few years. This means that if you’re using the MusicBrainz data right now, you will need to prepare your systems in order to be ready for the switchover when it comes in the fall. Please do not delay examining our new schema — this change is drastic change from our previous schema!

Our current plans are to enter beta testing of the new server on August 31. The exact release date is very much dependent on the results of our beta phase, but I hope to have the release within 60 days of entering beta.

The most important changes that you will need to consider/address:

  • No old (RDF) web service — the old RDF web service will no longer be supported as of NGS.
  • We will provide an XML v1 web service that is backward compatible to our current XML web service.
  • We will also provide an XML v2 web service that will expose new NGS concepts.
  • Postgres 8.3 will be required. Upgrading your old database will not be possible. You will be required to import the first post NGS data-dump in order to upgrade to NGS. Our provided upgrade script (see below) is very useful for testing purposes but not suited for upgrading deployed servers.
  • MBID changes — The MBIDs will be stable and maintained for artists, release-groups and tracks. All of the MBIDs for our current releases will also be kept, but we are changing what we are calling releases. Essentially all release events (with label, date, country and barcode information) will become releases each with their own MBID. This means that we’re adding a whole slew of new MBIDs for the releases that will not be assigned a legacy MBID.

NGS is documented on our wiki — please take some time to read up on our documentation! If you’d like to play with NGS now, follow these steps:

1. Download and install the 20090524 release according to these instructions. For going to NGS, installing a database only install is the perfect approach. Download and import an existing data set.

2. Download the NGS codebase with subversion.

3. Follow the install instructions. Instructions are included for how to migrate the 20090524 data to NGS — please note that the upgrade script may run for quite some time!

There are a lot of changes to the database from the current release! Please note that we’re done with the overall database design — I am not anticipating major changes past this point. However, I do anticipate a few smaller changes as we get closer to our goal. We will keep the schema diagram and documentation up to date with our changes.

If you care to follow our progress getting to NGS, please see our roadmap.