|
|
Developer's philosophy: Versioning
|
|
|
|
Addicted to MacNN
Join Date: Oct 2001
Location: Yokohama, Japan
Status:
Offline
|
|
I googled but didn't find anything helpful. I was wondering if anyone had links to sites that discussed best practices for versioning. For instance, how much needs to change to increment by 0.0.1 as opposed to 0.1? How often should releases be made? I'm holding back putting out another release of one of my apps because I just put a new version out two days ago. Any discussion of topics like this would be very helpful.
|
|
|
|
|
|
|
|
|
hayesk
|
|
If your new version is to fix a bug that could lose customer's data, put it out right away, no matter how recent your last version was.
If it's just a feature enhancement, I'd wait a bit. Are there other enhancements you need to do? If so, do those and then update your product. A month seems long enough to wait for minor feature enhancements.
I like to number this way:
0.0.1 bug fixes
0.1 existing feature enhancements
1.0 major feature additions or architecture changes
I also think an important thing to do is to publish release notes in an easy to find location on your web site (i.e. don't make them download your software to see what is new). Then the customers can decide for themselves if they want to upgrade.
|
|
|
|
|
|
|
|
|
Addicted to MacNN
Join Date: Oct 2001
Location: Yokohama, Japan
Status:
Offline
|
|
Of course it if was a critical bugfix I'd put it out right away. But a month seems like a long time to me. I've been putting releases out whenever I finish working on a new feature. I used to be doing about one release every 2 weeks, but lately I've been pretty bored so it's been one every 5 days or so. I'd wait longer to build up a cache of new features, but ideas usually come to me out of the blue (or are prompted by user requests/complaints), so I never really know when the next will come.
I'm just sort of thinking out loud here, so don't feel like I'm rejecting your advice. I'm interested in hearing any and all takes on this.
By the way, all my apps are freeware, so I'm not worried about losing revenue by pissing off my userbase, if I have one.
|
|
|
|
|
|
|
|
|
Grizzled Veteran
Join Date: Apr 2001
Status:
Offline
|
|
I'd lengthen your time between releases some.
No matter how easy it is, having to stop what you're doing to download the latest update of an application is distracting. I get tired of it quickly if an updated every 5 days.
Maybe rather than trying to update on a set schedule, you do something like this:
"I will normally update when I have integrated 5 new features. However, if I get say 3 new features integrated and two weeks go by and there's nothing new on the roadmap, I'll go ahead and release."
Wade
|
|
|
|
|
|
|
|
|
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status:
Offline
|
|
O'Reilly has a series on shareware development that might be useful. It also discusses press releases and other things applicable to freeware development as well as when to make new releases.
It basically reflects what wadesworld was saying. You want to offer new versions often enough to get people excited, but not so often that they get fed up with your product.
|
Chuck
___
"Instead of either 'multi-talented' or 'multitalented' use 'bisexual'."
|
|
|
|
|
|
|
|
Mac Enthusiast
Join Date: Nov 2003
Status:
Offline
|
|
Originally posted by hayesk:
I like to number this way:
0.0.1 bug fixes
0.1 existing feature enhancements
1.0 major feature additions or architecture changes
I use the same method, and from what I've seen it is a popular course of action -- I recommend it.
And as others have said, release major (e.g. crash) bugs as soon as you fix them. I typically collect a number of new features for a point (0.X) release and aim to get them out every 4-6 weeks. YMMV.
|
|
|
|
|
|
|
|
|
Mac Enthusiast
Join Date: Nov 2001
Location: California
Status:
Offline
|
|
After waiting forever and forever with Mozilla (it took me months to realize that it'd been nixed and reincarnated as SeaMonkey) I really like it when updates are fast. But that's just me. I can't wait for each new thing that just might make my day.
I have a question, if it's okay for me to tack it onto here, how do you implement version changes with Xcode? Do keep copies of the previous version's source code? To you make archives? Does Xcode have a feature to do this automatically without using a version control server?
|
12" Powerbook 1.5GHz/SuperDrive, 1.25GB Ram, 80GB HD, Airport Extreme, Mac OS X 10.4.11 Tiger
iBook (Late 2001)600MHz/Combo, 640MB RAM, 20GB HD, Airport, Mac OS X 10.3.9 Panther — web server
|
|
|
|
|
|
|
|
Mac Enthusiast
Join Date: Feb 2004
Status:
Offline
|
|
With Adium and Growl we tend to do easy fixes in the .x.x releases, and then a good amount of features in the .x releases. Neither have a 1. release yet, but they are both getting there.
|
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: Aug 2005
Status:
Offline
|
|
Originally Posted by ccsccs7
how do you implement version changes with Xcode? Do keep copies of the previous version's source code? To you make archives? Does Xcode have a feature to do this automatically without using a version control server?
Xcode has a Versioning build settings collection that lets you update project versions. If you want more control over the version number of the executable, open the target's information panel and click the Properties tab. From there you can set a version number.
If you want to keep track of the changes made to source code files, you should use a version control system. Xcode has support for CVS, Subversion, and Perforce.
|
|
|
|
|
|
|
|
|
Mac Enthusiast
Join Date: Feb 2004
Status:
Offline
|
|
Originally Posted by szymczyk
If you want to keep track of the changes made to source code files, you should use a version control system. Xcode has really lousysupport for CVS, Subversion, and Perforce.
fixt
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Forum Rules
|
|
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is Off
|
|
|
|
|
|
|
|
|
|
|
|