#204 Reevaluate the release process

v2.2
open
nobody
None
5
2014-02-13
2014-02-13
No

Well, this is not necessarily a bug report; take this more as a suggestion.

The problem I'm seeing is that the last releases of Sonic Visualiser came with some outstanding issues, like installation packages not installing, program crashes, some minor (or not so minor) usability issues, etc. And I see also that the main developers aren't having much time to work on SV, and I understand this perfectly (I'm not condemning you, Chris).

What I would like to suggest is to, before releasing a new version, publish a Release Candidate version, which could be tested by the community. This version could be announced on a mailing list, and by SV itself. SV could have an option in the Preferences dialog to notify the availability of beta versions (disabled by default, of course).

Despite the fact that SV as an open source project doesn't have a huge community, I'm sure that there will be some people (like me) interested in carrying on some testing when a new non-stable version arrives. And I think we and the end users can avoid some headaches if we have a pre-release version and we concentrate some testing, bug hunting and correcting in one week or two before launching a supposedly stable version.

That's all.
And thank you for tolerating my bad english... :-)

Discussion

  • Chris Cannam

    Chris Cannam - 2014-02-13

    I actually did this, one week before releasing v2.3:

    http://sourceforge.net/p/sv1/mailman/message/31719025/

    Nobody replied to that announcement, but that's not especially surprising. SV has a reasonable community of active users but I don't imagine many of them follow that list (not least because its name is "-devel") and even then, the probability of any given user getting around to testing and reporting on a pre-release build within one week is quite small. Also, of course, the Linux builds weren't there at that time.

    SV does have a forum, but I don't want to post pre-release announcements there because I don't want them to be too "persistent" -- I want to be able to remove the builds as soon as the proper release goes out. There is also a SV Twitter feed, though I don't think many people read it.

    The suggestion to have a preference to notify you when a release candidate or development build is available is a really nice one, I should do that.

    Apart from that, I really need to find a moment to look again into better build automation.

     
  • Josias Matschulat

    I apologize for not having searched carefully before posting. And I was not subscribed to the sv1-devel list, so I will subscribe now. You can count on me to test the RCs, at least one user will do this!

     
  • Chris Cannam

    Chris Cannam - 2014-02-13

    On the contrary, your "bug report" was a useful one. It's clear already that posting one note to sv1-devel (a list that gets very little use otherwise) with a limited subset of platform builds is not really enough of an advertisement for a new release to test. We could certainly do with a better way.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks