Clementine: "Releases are a PITA for the developers"

[AndydeCleyre]

Someone mentioned this in the Google Group discussion. I'm not sure if the speaker is a developer himself, or if he meant for developers in general or rather this project in particular, but it does seem to be the case, as it's been about a year and 8 months since a Linux release, and month more than that since a Mac OS X release.

At the same time, a lot of important features and bug fixes linger -- unreleased, largely dormant, and in a sense prisoner to the release cycle.

So this bug is about what can be done to make the release process less painful for developers (and consequently more rapid, for users).

So devs, what's working and what isn't? Do you think the team would benefit from the adoption of a more formalized branching model, such as feature-branch or git-flow?

[fitojb]

a lot of important features and bug fixes linger

It also sucks for people contributing translations!

[TheUbuntuGuy]

This probably doesn't answer your question, and I don't mean to offend anyone, but I just want to get my opinion on this issue out there.

I'm all for releasing once ready and I think that shipping flaky software is something that should be avoided at all costs. That being said, software is never "perfect" and there is a point where you have to draw the line and release. The reason I say this is because as we all know, Clementine will never be free of bugs.

The problem I have with the Clementine release cycle is that there doesn't seem to be one. It appears to be (and I very well may be wrong) that a release happens when @davidsansome feels like it. There is no heads up, there is no warning. There may be private discussions between @davidsansome, @hatstand, and @ArnaudBienner, but that does not help the other developers.

I feel like what would help the most is an "official" short list of "what has to happen before the next release". That would help identify the progress towards that milestone, and bring attention to the most pressing issues. I know there are problems right now, some quite major involving gstreamer, but are we going to delay the next release indefinitely until they are fixed? What about Qt5? Does that have to be done for the next release? Will the next release be something major like a 1.3 or 2.0?

I just feel like there should be a public way to see this information so that we aren't just committing randomly. I like going through the issues and fixing things that are interesting, but I would feel better working on things that are actually important in the release cycle rather than adding new features.

Is it an issue of time, where there is no one who can go through the issues and compile a list?

[hatstand]

Well, if someone wants to fix code signing for OS X on Mavericks & Yosemite that would help :-)

I guess one other blocker is the libprotobuf versioning issue with the spotifyblob.

[AndydeCleyre]

@hatstand Thanks, that's good information to have regarding the next release. Can you provide any notes or suggestions on how the process might be improved going forward?

[AndydeCleyre]

@hatstand I'm having trouble locating a bug report for the libprotobuf versioning issue, can you point me in the right direction? Is the OS X problem something that can be fixed in this code base, or is it really an OS X issue?

[AndydeCleyre]

Hey @hatstand or any other devs, can you give us an update on either this issue in general, or the mentioned OS X issue, or the mentioned libprotobuf issue, or the issues remaining between the release candidate from 3 months ago and an upcoming release?

Thanks for any info,
Andy