It depends on the customers approach to configuration control.
They have a choice, you know. Ultimately they can chose not to use your product.
If the customer will accept you changing stuff every day, and they don't care, and it has no training or configuration management impact; have automatic updates.
Customers with SOE ( Standard operating environments) hate updates.
Realize that some customers are not going to accept software "calling home".
They will want to host their own updates. Their IT people will have to get involved.
This is more work for them.
Some customers will want/need to do their own QA; depends on the customer and the kind of software.
If the customer needs to do testing/work to accept/deploy the software, release some multiple of the length of the test/deploy cycle. Unless the customers are okay with interleaved deploy and test. That's where they are always testing a new version, and the roll it out.
For example: 2 weeks to test, release not more than every 8 weeks.
In result critical software, release testing may take a customer months. They are betting their business on the results and are justifiably cautious. So releases are every 6 months or so.
In safety critical software, it may take MANY months. Annual, or about every 18 months is not uncommon. Even less often is quite normal.
The frequency of Wordpress releases is so frequent because they care about security and release updates that fix known vulnerabilities as quickly as they can. Functionality updates to Wordpress happen much less frequently, in the range of every 4 to 6 months I think.
I think this is a good model. Keep your customers happy by releasing new features regularly, but if you find security flaws, release fixes immediately.
You can release them as often as you want. The thing that frustrates users is not knowing whether they need your new version or not. This means that you need to be very clear about which new features you've implemented, the bugs that you've fixed, and whether or not you've fixed any security issues. More importantly, your users want to be able to trust that, if they do install a new version, nothing got broken.
I try to use the following, hopefully simple, two-part guideline:
If it requires the user to download and/or install something, or change an existing codebase that they maintain, then releases need to provide significant merit. This is a release that adds significant new features, fixed a significan amount of issues, or fixes a smaller number of immediate and pressing issues.
If it does not require the user to download and/or install releases will be planned to occur, as dictated by iteration. If there is a releasable product at the end of the iteration, it will be deployed. The iteration will contain technical and business needs as determined prior to the kickoff of the iteration.
So, for us, things like desktop applications or web services would generally fall under the first rule, and things such as our web site would fall under the second. We run fairly good sized iterations - at about four to six weeks of development time currently, decreasing to two to four next year. This was our "introduction" into a Scrum-hybrid.
Note that a product doesn't always have to be in development (or participating in an iteration). It is quite possible that a product will sit, stale, until changes are needed if the first rule applies.
{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','https://www.manongdao.com/data/attach/logo/logo.png', '推荐 再贱就再见 的问题《How often should you release software updates? [cl》','https://www.manongdao.com/q-1318997.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
Surely when you have new features/bug fixes worth releasing ?? Why have it on a schedule ?
Less frequently than iTunes updates.
It depends on the customers approach to configuration control.
They have a choice, you know. Ultimately they can chose not to use your product.
If the customer will accept you changing stuff every day, and they don't care, and it has no training or configuration management impact; have automatic updates.
Customers with SOE ( Standard operating environments) hate updates.
Realize that some customers are not going to accept software "calling home". They will want to host their own updates. Their IT people will have to get involved. This is more work for them.
Some customers will want/need to do their own QA; depends on the customer and the kind of software.
If the customer needs to do testing/work to accept/deploy the software, release some multiple of the length of the test/deploy cycle. Unless the customers are okay with interleaved deploy and test. That's where they are always testing a new version, and the roll it out.
For example: 2 weeks to test, release not more than every 8 weeks.
In result critical software, release testing may take a customer months. They are betting their business on the results and are justifiably cautious. So releases are every 6 months or so.
In safety critical software, it may take MANY months. Annual, or about every 18 months is not uncommon. Even less often is quite normal.
The frequency of Wordpress releases is so frequent because they care about security and release updates that fix known vulnerabilities as quickly as they can. Functionality updates to Wordpress happen much less frequently, in the range of every 4 to 6 months I think.
I think this is a good model. Keep your customers happy by releasing new features regularly, but if you find security flaws, release fixes immediately.
You can release them as often as you want. The thing that frustrates users is not knowing whether they need your new version or not. This means that you need to be very clear about which new features you've implemented, the bugs that you've fixed, and whether or not you've fixed any security issues. More importantly, your users want to be able to trust that, if they do install a new version, nothing got broken.
I try to use the following, hopefully simple, two-part guideline:
So, for us, things like desktop applications or web services would generally fall under the first rule, and things such as our web site would fall under the second. We run fairly good sized iterations - at about four to six weeks of development time currently, decreasing to two to four next year. This was our "introduction" into a Scrum-hybrid.
Note that a product doesn't always have to be in development (or participating in an iteration). It is quite possible that a product will sit, stale, until changes are needed if the first rule applies.