What is the policy on bug fixes to 2.5 release?

[atomatom]

I'd like to confirm (or not) the following understanding:

Once a major release is made, eg 2.5, no fixes are be applied to the release version - only against the nightly.

Therefore, the *only* way someone without support can get a bug fix is to use the latest nightly - which may come with many new bugs since it contains new feature development as well as bug fixes.

This policy makes me pretty depressed. I absolutely understand it from your point of view as a software development company.

If you have paid support, do you make fixes against the stable version rather than the nightly?

[Isomorphic]

Where did you get this concept? No that's not the policy, which is very very obvious given the patches in the Addendums forum.

[atomatom]

Thanks for clarifying. I was unsure, which is why I asked. I got the impression because there were several big bugs in 2.4 and sometimes the forum advice was to try the latest nightly.

I had not actually seen the the Addendum forum before. However, when I just checked it out, I saw only one mention of SmartGWT - presumably because all the bug fixes are in SmartClient (which makes sense).

So, to confirm how this works, if a bug fix is made against the release does

A) The zip file for the 2.5 release is updated and I can download and use that

or

B) All that is provided is the actual fix (in SmartClient). I then need to apply that fix in the SmartGWT Pro version that I have.

(If there is a page that clearly describes this policy, please point me at it. I don't want to waste your time.)

[Isomorphic]

Patches work for both products, see sticky post in Addendums.

Existing release files are never updated (no company does this).

We may or may not patch a given problem in a released version. A customer with Enterprise Support can request that any given problem be patched, other than that, we'll usually only patch serious problems.

If you don't have support, you may encounter something that is serious for you but not for anyone else, and hence have to run nightlies. The elevated service of getting patches for anything you want is a reason you buy support.

[atomatom]

Ok, cool. I checked out the sticky file and think I get it. So, I include the patch script after my GWT script tags in my HTML file and that should work?

Hmm... that does not sound like it should work, since the GWT JS will start running before you hit the patch script. Sounds to me like the include should be in the GWT module XML file, no? It would be great to have a sticky in this forum on how to apply patches in SmartGWT (and/or update the Addendum one for SmartGWT users).

I very much understand the policy for support - I just can't afford it (although going through the time I spend, it might be cheaper than fixing things).

Likewise, it would be kind of cool if you supported user contributed patches. Perhaps that happens in the SmartClient forum more than here.

[Isomorphic]

If a patch applies to SmartGWT it generally says so and instructions are inline (like this one). Much simpler than what you're thinking.

We routinely get user fixes, most just go into nightlies but some are re-posted as official patches if the problem is a common one.

[atomatom]

Ok, thanks. I hadn't read through all the patches and was confused since they all referred to SmartClient - kind of surprised many bugs don't affect SmartGWT, but that's ok. Another inference from this patch policy is that there are no updates to fix any GWT code - since you could not use the same patch method as for JS.

Where I'm going is that I'd like to continue to use SmartGWT to build applications - but as is clearly pointed out, the nightly builds are not production quality. I want to find a way to use SmartGWT that is as stable as possible.

Perhaps the only true way to do this is to pay for an Enterprise licence and support - which at last check put the cost at close to $5k in total (for my case).

[Isomorphic]

Not every nightly build is production quality, but many are, as conclusively demonstrated by the fact that they are actually in production at lots of sites.

Support or not, most well-reported bugs are fixed, and fixed quickly. Rather than agonizing over support policies, next time you believe you have a bug that affects your application, actually isolate it to a test case instead of just providing anecdotal evidence that there might be a flaw, and dropping the discussion (you have done this multiple times). Doing this while complaining that you've encountered stability problems is absurd.

[atomatom]

Not every nightly build is production quality, but many are, as conclusively demonstrated by the fact that they are actually in production at lots of sites.

Yes, I'm aware of that. Unfortunately, most of the time this is a test-and-see-yourself process. I've done that, and I've stuck with certain nightly builds because I had gone through this process and was pretty sure it was stable.

Support or not, most well-reported bugs are fixed, and fixed quickly. Rather than agonizing over support policies, next time you believe you have a bug that affects your application, actually isolate it to a test case instead of just providing anecdotal evidence that there might be a flaw, and dropping the discussion (you have done this multiple times). Doing this while complaining that you've encountered stability problems is absurd.

I'm not agonizing, I'm trying to determine how I can use SmartGWT in a product environment without spending a lot of time testing your code.

In quite a few cases, I have provided test cases and you've fixed the bugs (you don't mention that - you seem to say I have not done this). I appreciate this. And I believe you appreciate the free QA. We both win. Sometimes, I don't have the time to produce a standalone case and post an issue I'm having and it is ignored (and rightly so, if I *strongly* agree with your fix-only-on-test-case policy: sometimes, it is not a bug in SmartGWT code). In cases where I feel there is a moderate chance it could be a real bug, I post it, even if I don't have the time to make a test case.

The issue I have comes down to this: I produce a test case, you fix the problem, the only way I can make use of the fix is to take the latest build (which may/may not contain other nasty surprises).

[Isomorphic]

The issue I have comes down to this: I produce a test case, you fix the problem, the only way I can make use of the fix is to take the latest build (which may/may not contain other nasty surprises).

.. and this is indeed what we expect if you do not purchase support. In a nutshell:

1) every release of every product has flaws

2) we offer support plans where you can get patches for any flaw you find (an amazing level of service, unique in the industry as far as we know)

3) if you can't afford support, we general fix well-documented bugs anyway. But you want fixes for flaws that we don't feel are worth publicly patching, the tit for tat is that you help identify bugs on an ongoing basis. Here too, it's extremely unusual if not unique to find a company that is as aggressive in fixing bugs as we are.

[atomatom]

Yep, that all makes sense. Thanks for clarifying and confirming.