PureBasic 5.11 is out !

[Danilo]

I agree, it would be nice to have written down what has been fixed, because they don't fix all known bugs
before release.
Not easy to always know what has been fixed and what was not fixed. It is required to know what has been fixed
to know what features I can use again or still can't use because the bug has not been fixed.

Assigning numbers to bugs would help. Like in bug trackers, so history could provide info with link:

Code: Select all

Fixed Bugs:
#56883 Operator precedence
#56953 Memory leak with p-ascii, p-unicode, p-utf8
...

Maybe fixed bugs should get moved to a public forum category, so the link/number could be the number of the bug topic.

[skywalk]

Yes, we are all in favor of better bug tracking.
Serializing them is a good 1st step.
But, it gets tricky when you want to differentiate IDE bugs from Math bugs or VisualDesigner bugs.
These scenarios have all been accounted for in modern bug trackers and relational databases.
Reinventing the wheel doesn't seem worth the effort here?

[RichAlgeni]

As developers, no one knows better than us that shit happens! That's why:

1. We test code to make sure it does what it's supposed to do.
2. We use source code management, so we can check differences and revert to a different version just in case.
3. If everything is running they way you want it to, you don't need to upgrade!

Keep using the version you have currently, until you are able to test and certify the results.

If possible, you should create test scripts or scenarios, which have predefined results. You can then run through these tests and fairly quickly know if there's an issue. It seems to me that you might be more concerned with changes in functionality, of which I believe there are very few of.

Relax for a moment, and take a deep breath. A number of us here develop commercial products on PureBasic. I just upgraded (last weekend) 5 servers at my largest client with code generated by PB5.11 x64, and everything seems to be going smoothly.

[rsts]

still maintain certification if we know what bugs were fixed so we can develop the fixes/updates/replacements.

If you can maintain "certification" based on a bug fix report, the certification is largely a sham.

[SFSxOI]

If you can maintain "certification" based on a bug fix report, the certification is largely a sham.

You misunderstand, its not maintaining certification based upon a list of bugs known or a bug fix report. Its knowing the bugs that allows us to develop updates/fixes/replacements that can be certified for the deployed code needing replacement/fix/update. Knowing the bugs fixed lets us do that because we know what areas to look for and upon what and where to focus the updates/fixes/replacements. Knowing the bugs fixed also lets us determine which code is affected and lets us target that code, each and every variable, function, line number, and every aspect of the code is documented and records kept so we know exactly where something is so knowing which library bugs were fixed tells us what functions were used in what deployment and in what specific item (each item is application specific, its not just an 'app' to be changed or fixed or upgraded, each item is unique to its specific application) and knowing that lets us target that deployment. Its a certification process that is obviously unknown to you and many simply because you never had to deal with it before so I don't really expect you to understand.

[rsts]

25 years in Pharmaceutical NDA's - FDA regulated - I understand GMP, GLP and certification.

Don't talk down to us.

[SFSxOI]

25 years in Pharmaceutical NDA's - FDA regulated - I understand GMP, GLP and certification.

Don't talk down to us.

I'm not talking down to anyone. Just pointing out its not as simple as what everyone wants to think. Our certifications (composed of several certification processes from OS's to CERT to Legal to contractural to industry to ISO to networking to security to InfoSec to even (when it applies) law enforcement (and sometimes in other countries), not to mention the procedures/process/methods and facility certifications for the government contracts, are not a linear process 'do this then this happens' or 'do this for this to happen' or 'if this happens then do this' type of thing like almost every respondent to my posts in this thread has attempted to address or describe and no where near such. I wish it was as what your posted experience implies 'cause i'd give you a nice $80K a year job in a heart beat and let you handle it

I'm sure you understand what you were familiar with, but i'm also equally understanding (judging from your reply) that you don't know the type of certification process involved with what we deal with which is a completely different thing.

[dman]

c'mon peeps, let's not fight

let's make code together lol

[MachineCode]

we have to recall every single piece of code in the field and decertify everything deployed we have done with PureBasic until its tested again

Surely you can do it a simpler way?

[rsts]

Just pointing out its not as simple as what everyone wants to think.

You seem to be the one who thinks it's as "simple" as Fred telling you what changed. If that's the "certification", it's a sham.

You want to know what libraries changed? Look at build dates and file fingerprints. Fred can't tell you what changed. He doesn't know. No one does. How many instances have we already seen of new bugs being introduced in 5.11? Even with a file fingerprint confirming a library is the same, who can say it hasn't been used in a way it was never used before? New bugs come up in "libraries" all the time - look at sqlite.

The only "certification" is an accepted set of regression tests which stresses the environment utilizing a predetermined and approved methodology. You can't "take someone's word" as to what's the same and what's changed.

[skywalk]

The only "certification" is an accepted set of regression tests which stresses the environment utilizing a predetermined and approved methodology.

Exactly. Depending on the scope of your app, you can build a set of tests to guarantee obvious errors. And you can compare reports from previous versions to determine if your app or the compiler is the culprit. I don't create gui intensive apps so I am spared much of that grief. But memory leaks, hangups and math errors are my devils.

[SFSxOI]

Anyway, back to my original question ....

What got fixed or changed? The history in the help has this > "Fixed: Some compiler and libraries related bugs "

But what related bugs? Need to know, so I can evaluate if code in the field needs to be updated, rescinded, or if vulnerabilities exist that need to be immediately addressed. So what are the fixed bugs?

[sartic]

i do not like also. but answer was giving here... to read forum; but anyone have no time and capabilites to catch all

[Danilo]

i do not like also. but answer was giving here... to read forum; but anyone have no time and capabilites to catch all

Read the forum instead coding! Sorry, couldn't resist...

[DarkDragon]

A long time ago there was a bugtracker project, but it has never reached the public. I've always wondered why.

It is still online, but maybe I've told you too much - it was a secret.