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@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@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@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
