I saw in the news field that the latest update including the long awaited “alternative tracklists” [MBS-8938] were postponed from 2016-05-16 to Monday 2016-05-23, but what happened since then?
I haven’t seen this new feature on the website? Is it live yet, and if yes, how does it work and where is it?
I feel like I don’t speak the same language when I read the news blog article on https://blog.musicbrainz.org/2016/05/25/schema-change-release-2016-05-23-with-upgrade-instructions/ when it mention stuff like web servers and you need to install “PostgreSQL 9.5”. Sometimes I feel like MusicBrainz has other “under the hood” parts than the website musicbrainz.org, is it true? 
1 Like
In this case, that is true. Issue 8938 takes care of the database schema side of alternative track lists. That is, how these track lists are represented in MusicBrainz’ database. That is an important step, but issue 4501 will have to be implemented too before it can actually be used on the site. I don’t know whether someone has started work on that yet. I hope it’s done soon!
2 Likes
Oh, I see! I didn’t knew that there were several tickets for this feature. I actually thought that 4501 was directed to 8939 that was suppost to go live and give us a new feature on the website. That hasn’t happened yet, right?
Well, as you can see 4501 is still open, and we can’t use alternative track lists yet, so no, it hasn’t happened yet. 
The last comment in 4501 says “unfortunately that’ll be delayed by a month or so” - so I imagine that’s the best estimation we have 
As I understand it, as a fellow non-coder/non-technical wizard, the actual system now has the capability to store alternate tracklists, but we still need to make a UI + display for them (eg the buttons for editors to press to enter the tracklists, and how things should be displayed when you visit the release page on your browser).
Someone correct me if I’m wrong!
2 Likes
Others have mentioned there being two tickets.
A bit of background: „schema changes“ (i.e. the underlying database changes in an incompatible way) only happen twice per year, so the developers try to cram as much as possible into them (this time, the version of the database software was changed as well). This makes these both a rare, and more harrowing experience.
Other changes happen much more frequently, are more incremental, and usually much less stressful. Many features do not require a schema change and can be implemented right away. Those features, like alternative tracklists, that do, are often split into two parts: the database (schema) change, and the web server (frontend) change. If this were not done, the schema change upgrades would be an even bigger chunk of work.
4 Likes