Stable release

[rpedde]

Okay, I’d like to start working toward a new stable, and am asking for opinions.

Here are the things I want to fix before a stable:

1. Finish the io abstraction stuff
2. Fix the db abstraction, and put back the gdbm backend
3. Move playlists to files
4. Finish the renaming, and make everything refer to firefly, not mt-daapd
5. Small misc patches and fixes I have pending (some web interface patches, autoconf patches, wav parsing fixes)
6. RPM packages for nightlies
7. Fix web config buglets

Stuff that’s on the timeline, but I intend to pass on for the next stable release:

1. UPnP
2. Scripting plugin (lua, or ruby, or both?)
3. Playlist improvements (top n, sort by)
4. Move scanners to plugins
5. Implement taglib-based scanner
6. Growl integration (mac)
7. Sparkle integration (mac)
8. Help file (culled from wiki)
9. Updated ffmpeg for windows

There are a couple things I want to change before a stable:

1. Version numbers – I want to sync this with the Roku releases to avoid confusion. I think the best way to do that is to call the upcoming stable release “v1.2”. Opinions? That’s a big jump from 0.2.4 to 1.2. 🙂

2. DB playlists — I’ll have code to migrate from in-database playlists to file-based playlists in v1.2, but will be deprecated, and removed before a “1.3” release.

3. state_dir. I want to specify a single directory for storing server state. I’ll use that directory for the path to store the db in, as well as the file-based playlists, and other misc stuff I might need (cache dir for transcoded files, maybe, or per-user playlists, or other stuff). So the db_param parameter will be empty for sqlite and sqlite2 databases, and will only be used for backend databases that require configuration (like mysql or postgres).

All that said, I’m soliciting feedback. Does anyone have anything they think should be in the “must do before 1.2” list? Or anything they feel should be moved up from the “not going to do” to “must do” list?

Anyone have any opinions on the version number?

Any specific small fixes anyone thinks must be fixed pre-1.2?

Feedback, please.

— Ron

[SydneyGuy]

Just fix the HUP bug in the next stable 🙂

One thing important with stable releases is the ease of upgrading. Lots of people only ever install the stable releases whilst many are always on the bleeding edge. Your upgrade process needs to take both of these scenarios into account. We don’t want to have to start from scratch again.

I think it is important to get the next stable out as soon as possible. The main reason is that Firely is being included with some NAS devices and the manufacturers of those devices will probably only ever include the latest stable. The version currently being included is VERY old so a new line in the sand would be good.

[fizze]

There also seems to be some bogus in 1586 that has to do with firefly not finding or loading its plugins.

I guess it wouldn’t hurt to check on that and add a warning of some sort on the web interface. Probably add a link to the wiki there, or something like that.

Other than that your schedule sounds fair. Way to go! 🙂

[S80_UK]

My suggestion – wrap up the stuff that you want to and make that 1.2. Sure, it’s a jump from 0.2.4, but it will be necessary to sync with the Roku numbers at some point, and the forum messages indicate that many users look to whatever is hosted by Roku as an “official” version.

Then look at UPNP. If other stuff fits in with that then that could be done in parallel, but I feel there is significant demand for a UPNP server with the stability and footprint of Firefly, so make that 1.3. That would also appeal to some of the NAS vendors, who often ship with relatively limited UPNP implimentations. The Mac stuff, plugins, etc, are all good, but for me at least would be part of a 1.4 release.

Just my 2 cents.

Thanks for asking,

Les.

[Anonymous]

I can agree with S80_UK, what I miss most is uPNP support. That would be really good as I have both a Roku and a PS3.

[rpedde]

@alfaskop wrote:

I can agree with S80_UK, what I miss most is uPNP support. That would be really good as I have both a Roku and a PS3.

Okay, good. That sounds reasonable, as I want to get on a faster stable timeline, and let less creep get in.

So wrap up for 1.2, UPnP for 1.3 (maybe scripting, as that’s my favorite itch, plus I’ve been writing ruby bindings for C at work, so I think I can make short work of it), and everything else post 1.3.

Any other opinions?

[rpedde]

@fizze wrote:

There also seems to be some bogus in 1586 that has to do with firefly not finding or loading its plugins.

Do you have more details on this? I know there are some config page issues, and problems with initial db scan, but don’t think I remember the plugin thing.

[Anonymous]

@rpedde wrote:

@fizze wrote:

There also seems to be some bogus in 1586 that has to do with firefly not finding or loading its plugins.

Do you have more details on this? I know there are some config page issues, and problems with initial db scan, but don’t think I remember the plugin thing.

I had some issue with 1586 where it would fail to start if i moved some plugins from the plugins directory. May have been due to still having the ssc* lines in the config file but not having the plugin available? Can’t remember now.

BTW, if you’re thinking about scripting languages, my vote is for python! 🙂

_

[fizze]

@rpedde wrote:

@fizze wrote:

There also seems to be some bogus in 1586 that has to do with firefly not finding or loading its plugins.

Do you have more details on this? I know there are some config page issues, and problems with initial db scan, but don’t think I remember the plugin thing.

I’ll see what I can come up with and sum it up for you.
I just noticed a lot of problems due to not-loading plugins here recently, all with svn-1586. *Shrug*

Maybe it’s as simple as creating a red blinking warning message on the webinterface that yells when firefly has loaded zero plugins 😉

[rpedde]

@Underscore wrote:

BTW, if you’re thinking about scripting languages, my vote is for python! 🙂

_

I looked at embedding python in C and it looked downright ugly. Ruby has some threading drawbacks, but writing a C/ruby bridge is a downright pleasure. And lua was designed for it, so it works good, although again, it doesn’t do threading well, instead favoring coroutines.

Still, I might look at it. Or perhaps once the scripting interface is stable people will flock to contribute scripting plugins. (vbscript, python, perl…)

Hrm. Or not, probably. 🙂

— Ron

[Author]

Posts