proposed solution for defects 90095 & 119539 (674 votes, 638 votes) (Multiple artists per song)
Jeff Mitchell
kde-dev at emailgoeshere.com
Sat Aug 30 20:38:12 CEST 2008
On Thursday 28 August 2008 07:51:54 Devon Jones wrote:
> I talked with a number of devs on the irc channel, and asked them about
> these bugs, and essentially they said that 2.0 will freeze the database
> schema for future releases, and there is presently no plan to allow for
> anything more then the present 1 artist and 1 composer per track.
Probably for 2.0 releases, at least, not 2.x where x >= 1.
Really, we can modify the schema whenever we decide it's necessary. Because
we'll be standardized on one type of database (hopefully mysqle) it will make
it far easier than 1.x in that regard. But it requires being very careful,
and every time you want to make a change, the list of things that need to be
changed from 2.0 get longer and longer. So don't think that we can never make
crucial changes to the database, but they are likely to wait for minor
releases instead of point releases, and we're likely to try to make changes
all at once.
One other note: I think for A2 we should make a habit of creating a copy of
the user's collection file -- easy if it's embedded, i.e. sqlite or mysqle --
every time we run the database updating function. If we cannot make that
copy, we should not continue with the upgrade; also, this way, if a user says
that the upgrade toasted their collection, they'll have a backup to work from
to try to figure out what's going wrong.
--Jeff
More information about the Amarok-devel
mailing list