Page 1 of 1

How should I handle new releases?

New postPosted: Mon Jan 05, 2009 7:58 pm
by marwatk
Hi all,

So I've been adding new features at a pretty quick pace, but that also means I've been introducing bugs just as quickly. My goal was/is to try to get it feature complete as quickly as possible, then get the bugs ironed out as they came up. This has, understandably, annoyed some people, as they'd upgrade to a broken version and couldn't play their podcasts.

I wanted to get feedback on how you'd best like me to release new versions. It generally takes about a week (from past experience on this project) for a release to be tested enough that all of the features introduced work as designed. Unfortunately, while those bugs are getting discovered and worked out, I'm also adding new features, and so there's never really a point where there are 'stable' versions.

There are a few options:
1) Keep going as I have been, putting out features at a breakneck pace, but introducing bugs at the same pace.
Pros: More new features faster, everyone gets to try the new features, notified of new versions
Cons: Buggy as hell until the features calm down, impossible to tell if a new release will work for everyone from the get-go, not always possible to downgrade

2) Introduce beta versions and release versions
I don't have the resources to keep to versions in sync, a release and a beta, so what would happen is all new development would happen in a beta, the beta would be released, and then new feature development would stop while we discover bugs in that beta. Once the bugs are worked out the beta is moved to the latest release and a new beta with new features is started.
Pros: More reliable releases, only those that want the latest risk breaking stuff
Cons: New features would be added at about half the rate (or slower) than they are now, would only be notified in podtrapper of release editions

3) Some other option I haven't considered (post details in this discussion).

So, here's the poll, let me know what you think.

Re: How should I handle new releases?

New postPosted: Mon Jan 05, 2009 10:19 pm
by hunberry
Hi Marwatk,

I appreciate all the things you do.
Please slow down before you burn out.
During the last month I could barely keep up with downloading new releases
and discovering new features.
I was too busy listening to podcasts :lol:

My vote is (2) but at a much slower space than before.

Maybe other users could recommend you to develop another mobile application in the meantime?

Hunberry

Re: How should I handle new releases?

New postPosted: Tue Jan 06, 2009 12:15 am
by ag5bpilot
Unless you're going on vacation (in which case a stable release would be nice), I'd keep going the way you have been.

When new bugs come up, you've been squashing them quickly. I can live with a buggy podreader for a day or two.

Bottom line is, what works best for you? Personally, I'd rather see you expend effort writing and debugging code rather than managing releases.

After a while, everyone will run out of ideas and things will slow down.

Re: How should I handle new releases?

New postPosted: Tue Jan 06, 2009 9:29 am
by Tom Munch
Marcus,

Maybe you could have us be your beta testers here before you make an incremental release official. That way we could iron out the bugs before you release things.

Just a thought. I've seen this done with several other titles.

Tom

Re: How should I handle new releases?

New postPosted: Tue Jan 06, 2009 2:13 pm
by Lion
I agree with the rate that things are going now .. as long as there's new ideas and bugs to be fixed and energy to do both, go for it. When the product reaches maturity and new ideas are coming at a much slower rate, then incremental improvements can be made (like refactoring for better performance, etc) ... the top reason I said "buy it" was the clearly active forums and responsive developer. It looks like this style of podcast aggregator on BlackBerry is relatively new and I wanted to buy one that was being developed, was adding new features, and had a developer that listened to his customers.

Re: How should I handle new releases?

New postPosted: Tue Jan 06, 2009 2:26 pm
by jzamoras
Bring'em on!! :-)

Re: How should I handle new releases?

New postPosted: Tue Jan 06, 2009 3:41 pm
by mike240se
lets face it, everyone loves this kinda speed. and it makes sense since the program is not really done. but if you want to post beta releases that are as "stable" as possible then i would def. help test.

of course if something is expected not to work for any reason, please let us know. some of us would not want to install betas with known issues while some of us might want the new features the beta has.

Re: How should I handle new releases?

New postPosted: Tue Jan 06, 2009 8:28 pm
by hoshposh
Hi Marcus,

If you can handle this break-neck speed of delivery then please feel free to continue. I have been very impressed with the amount of change and constant improvement I have seen in the product. Having said that, please don't burn out and go to the other extreme and not release anything ;)

While I voted to keep going, maybe the next best thing is to quickly establish some immediate goals for this round of features, then keep going till you feel you have met those goals. Once that is completed, go down the path of beta or development releases for those who want to stay on the bleading edge, while providing stability to those that would prefer that.

Anyway, I don't think this is an open source project, but if you need help with testing I am sure there are enough people who would not mind lending a hand so that you remain energized.

Cheers,
-Lyndon-

Re: How should I handle new releases?

New postPosted: Wed Jan 07, 2009 12:50 am
by fbotha
You've done a excellent job and would prefer you to keep doing what you have been doing!

However - to keep everybody else happy, why not have older versions up for download as well ? If a big mistake was made one could then just roll back to a previous version.

Regards,
FB

Re: How should I handle new releases?

New postPosted: Wed Jan 07, 2009 5:31 am
by audioeng
The only recommendation I would make is while releasing at the same speed, include version changes or a link to version history on the upgrade page that PodTrapper sends you to, so the user can easily tell of changes before deciding to upgrade.
I currently after clicking yes to update have to enter your site manually and scroll past all the screenshots to read the version history. It would be nice if there was a link that showed the changes right from the upgrade page.

Re: How should I handle new releases?

New postPosted: Wed Jan 07, 2009 8:33 pm
by ahagenmaier
I like the beta version idea. Or at least mark a "stable" version for people who don't want all the headaches (maybe spend a day once a week just on bugs to release a new stable version??)
For me it isn't a huge deal if I have a buggy version for a day and I almost always take the new release.
I agree with the other poster that wants a easier way to the version history (at least it's own page that I can bookmark).

Re: How should I handle new releases?

New postPosted: Sun Jan 11, 2009 7:20 pm
by marwatk
Hi guys,

Thanks for all of the feedback, I really appreciate it.

I ended up going with a hybrid of the first two options. My day job made the decision easier, since during the week now I can't really get a lot of features in (only working on it at night). For new releases with major changes I'll be releasing them in a pre-release fashion, these will usually come on weekends. They're not beta's per-say, but they won't trigger the update alert. If no show stoppers are found by the brave souls willing to try them out, toward the middle of the week I'll migrate them to a real release (with any minor fixes also made).

Hope this makes sense, thanks again for the feedback.

-Marcus