Page 1 of 1
Small changes, release often or Big changes, release less?
Posted: Mon Aug 14, 2006 4:47 pm
by Chris Corbyn
I personally like to keep pushing out new releases of code even if the changes I've made are small. I think it's healthy to have a code base which keeps improving, providing that every time you release a new version you don't require your users to modify anything.
It seems many people think this is silly though. What do you guys see as a good development cycle?
I make new releases around once a week although I have bursts where new releases will appear every couple of days. Obviously as the code matures more and more the releases will possibly become less frequent.
Posted: Mon Aug 14, 2006 4:56 pm
by feyd
Reguarly updated to me means there is actual active development going on... Otherwise, unless the developer says somewhere you can find, you have no idea what the status is.
Posted: Mon Aug 14, 2006 4:57 pm
by MarK (CZ)
Not only there's always the most recent version available but the project also looks more serious with more "life" on the site where it's published.
Definitely better to release often but sparingly, not just because of adding one more dot in the output..
Posted: Mon Aug 14, 2006 7:55 pm
by Ambush Commander
While I agree that an actively released project is good for image, you also have to keep users in mind. If you release too often, users may still get lazy and not update (even if there's little to no risk). I like stable libraries.
Posted: Mon Aug 14, 2006 8:07 pm
by Nathaniel
Ambush brought up a good point. For an application like phpBB, I'm with the Commander: keep things stable. If I'm developing an application that will run in only one place, however, then releasing often is the best choice.
Posted: Mon Aug 14, 2006 8:10 pm
by Ambush Commander
If I'm developing an application that will run in only one place, however, then releasing often is the best choice.
Right. If you're real crazy (like the MediaWiki developers), you'll run the code straight out of the repository with little to no lag time.
Posted: Mon Aug 14, 2006 8:37 pm
by Weirdan
If you're real crazy (like the MediaWiki developers), you'll run the code straight out of the repository with little to no lag time.
Which I do as well on testing servers. I find it's easier to use WebDavFS to run the latest trunk code straight from the repository than to wait until the test pad would pick up the latest changes (never bothered to create appropriate post-commit hooks).
Posted: Mon Aug 14, 2006 8:39 pm
by Jenk
You can cater for both worlds with snapshots for the latest latest stuff, intermediate releases on say bi-quarterly dates, and 'official' releases for big updates - just like any major open source project tends to do.
Posted: Mon Aug 14, 2006 9:00 pm
by RobertGonzalez
Smaller updates, but not like everyday updates. If there are issues that need resolving in the code, then resolve the issues and post an update. If there are things that users/developers want to see in the code, develop those as time permits, then when the next update ocurrs, include it. I think too many updates kills the interest in an app ('Does the product keep changing because they haven't gotten it right, or what's the deal?').
Posted: Mon Aug 14, 2006 10:01 pm
by neophyte
"Release early, release often"
Yup, that pretty much sums it up.