paying for bug fixes (was Re: [ANN] Installer Maker Plugin 1.7.8)

[Dar Scott]

Hi, Bob!

Would it meet the intent of what you are saying to essentially close the bugs-to-be-fixed list for a major release some period of time--say a month--after the release of the next major release?  (With the caveats of "may opt to do so" as you say.)  Or should that period be in the 3 months to 11 year range?  That is, the person who bought the earlier release just before the new release was (uh) released would have a month to say that the product does not work with his stuff.  

Dar

On May 4, 2012, at 3:41 PM, Bob Sneidar wrote:

> If I may chime in here, if there is a bug in a prior major revision, and no one called to say so, and there is no maintenance contract, then I think the end user should pay for the new major version. You may as a favor, and if you know what the problem is, do a bug fix and release it, but that would be up to you IMHO. Also, if no one called to report the bug, it was either no a very big one, or else not a very commonly encountered one, or the end user was thinking, "I'll not bother to report it." In any case it doesn't seem fair that the developer should be REQUIRED to fix it, but of course may opt to do so in the interest of good customer relations. 
> 
> Bob
> 
> 
> On May 4, 2012, at 1:40 PM, Dar Scott wrote:
> 
>> Thank you, Tim.  This is very clear and attractive.
>> 
>> I do have a question.  If Product X is on version 8.8 and a customer is using 1.0.5 (released 11 years ago, just before 2.0.0) and finds a bug, do you fix the bug?  That is, do you create version 1.0.6? 
>> 
>> Another.  If Product Y is on 1.5.8 which has not gotten bug reports for a couple months and you create a new and better version with major feature changes and plan to release it as 2.0.0.  However, some bug reports come in for 1.5.8 and the bug does not occur in 2.0.0.  What do you do?  Do you release the new major release as 1.6.0 (update) or do you release it as 2.0.0 (upgrade) and then work on 1.5.8 ignoring complaints about 2.0.0 bugs until 1.5.8 is out, or do you hold off on releasing 2.0.0 until 1.5.8 is out?
>> 
>> is a change in a minor digit an upgrade or an update?
>> 
>> Dar
>> 
>> 
>> On May 4, 2012, at 1:38 PM, Tim Jones wrote:
>> 
>>> On May 4, 2012, at 12:13 PM, Dar Scott wrote:
>>> 
>>>> What would you hope for, look for, in bug fixes when you buy a product?  In particular, if I put something into a storefront window and, in some fit of insanity, you bought one, what would you think is a reasonable bug-fix policy for your purchase?  Or your niece bought one?
>>> 
>>> If the product is advertised to offer a feature, and that feature is missing, incomplete, or doesn't work as expected, I would expect a bug fix.  This is an "update".
>>> 
>>> If the product is not advertised as having a feature, and you add it, I would expect it to be a new version.  This is an "upgrade"
>>> 
>>> For my products, I use a 3 place version identifier - major.minor.bug
>>> 
>>> If I release a new project - it's 1.0.0
>>> If I fix a bug or two - it's 1.0.1
>>> If I add a simple feature or improve an existing feature - it's 1.1.0
>>> If I add a new set of major features - it's 2.0.0
>>> 
>>> My customers "always" get bug fixes and minor updates as "updates"
>>> They only get "upgrades" for free if they have a support and maintenance plan otherwise they pay a 50% upgrade fee for the new version.
>>> 
>>> This has worked for over 22 years and our customer base is very happy in how we treat them.
>>> 
>>> Tim
>>> 
>>> 
>>> _______________________________________________
>>> use-livecode mailing list
>>> use-livecode at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> 
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode