A formal process of releasing patches?

[leizaola]

Hi, it seems that when you guys release some software or patches, you blast it out and then you let people go down in flames with any bug that may have been added and then have sergey firefighting.

The current patch release method many of the posts are about "is it safe to use the patch now?". Obviously whilst we see a pile of bug we are reluctant to introduce something that might bring out sites down.

Would it be a good idea for patches to be released a sub code (E) for early release and when no one has reported a bug on that patch for say 2 weeks it becomes a (G) general release? Any final bug found in that release is then put in a (S) stable release.

Us users can select whether we are going to run with a stable version or we are going to have all the latest features at the expense of having bugs.

03. seems to fix a pile of problems. I've never seen a 03 release that fixed that 30 bugs in one go! well done.

[Simon Gooffin]

Got your idea. Thanks for sharing it. We will think over your idea. Of course we make preliminary tests for all our patches, etc. But you are right there should be spent more time for testing purposes on different hosting platforms by different persons.

[leizaola]

You actually don't have to do more testing. If you do it will be great. But just have several release levels so people can select if they want to be on the bleeding edge or want to install stable code.

All major software that is critical has Alpha1,2, Beta1,2,3, Release Code1, Releaase, then stable.

In the stable you can collate all the bug fixes.

[leizaola]

Could you please tell us when 2.1.03 is ready use. I still see more complaints about it than 2.1.02