You are here: Home » Topic » Stable release

Stable release

This topic contains 13 replies, has 7 voices, and was last updated by  nswint 10 years, 3 months ago.

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #1595

    rpedde
    Participant

    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

    #11879

    SydneyGuy
    Participant

    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.

    #11880

    fizze
    Participant

    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! 🙂

    #11881

    S80_UK
    Participant

    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.

    #11882

    alfaskop
    Participant

    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.

    #11883

    rpedde
    Participant

    @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?

    #11884

    rpedde
    Participant

    @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.

    #11885

    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! 🙂

    _

    #11886

    fizze
    Participant

    @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 😉

    #11887

    rpedde
    Participant

    @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

    #11888

    baldrianus

    Firefly 1.2 stable should ensure, that this version supports both:
    Roku and Pinneacle Soundbridge in Windows and on NSLU2/Linux!
    (Pinneacle version of Soundbridge is usually sold in Europe)

    Regards

    Achim

    #11889

    nswint
    Participant

    @rpedde wrote:

    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

    rpms please 🙂

    you forgot about the fedora crowd

    😥 😥 😥 😥 😥 😥 😥

    #11890

    rpedde
    Participant

    @nswint wrote:

    rpms please 🙂

    you forgot about the fedora crowd

    😥 😥 😥 😥 😥 😥 😥

    I’ve got specfiles for fedora7/rhel5/centos5 thanks to some fedora contributers. I’ll be rolling those as well.

    — Ron

    #11891

    nswint
    Participant

    @rpedde wrote:

    @nswint wrote:

    rpms please 🙂

    you forgot about the fedora crowd

    😥 😥 😥 😥 😥 😥 😥

    I’ve got specfiles for fedora7/rhel5/centos5 thanks to some fedora contributers. I’ll be rolling those as well.

    — Ron

    rank roo 😀

Viewing 14 posts - 1 through 14 (of 14 total)

You must be logged in to reply to this topic.