Updating Philosophy

By: | Post date: April 9, 2008 | Comments: No Comments
Posted in categories: Cocoa, Strategy, Uncategorized

Developers are told repeatedly to “ship code to real users” and get feedback. How does this translate into the customer experience and their update cycle?

What do you think?

I’ve decided recently to move away from packaging up point releases and instead ship more frequent updates via the Sparkle+ framework. This will allow me to keep my motivation and engagement up, but could impact the user who will see more frequent updates. Which is a better approach for customers? Post a comment or ping-back with your thoughts.

On a related note

I’m working on several new features in MagicBrush-Photo that will be developed incrementally over time. In parallel there are bug fixes and minor tweaks occurring within the code.

In a multi-developer group, a more rigorous release plan and management would be a given (I hope). But for a single developer, do I really want to spend time maintaining branched code (current and development) and merging things back together for a release?

I’ve decided to not keep code merged and instead created a framework for setting a flag within the preferences of the application to enable development/partially complete features. This way, I can send a stand-alone script to testers to turn-on features within the current release.

Hopefully, these two changes in my approach will help me drive some significant new features more quickly to the users of MagicBrush-Photo