Generally, projects do not have rigorous automatic testing. So yes it is generally true.
QED
I guess there is also
5) despite pointing out obvious realities, people immediately deny them. The first step to solving a problem is recognising the problem.
It’s not true because it’s not a catch 22 when there is a 3rd valid option available: build rigorous automatic tests. I agree with the general message, specifically if applied to kicad. Still wouldn’t generalize it to all software though.
I think you are nitpicking, people seem to love arguing over semantics. My point of “a wider audience” was “to get wider test coverage”. That can be achieved by manual test or automated. An intelligent developer would understand that, and I think you to do.
In an ideal world, automation tests everything. Of course, there is still the problem that you don’t know everything that needs testing. Back in the real world, none of the professional projects I have worked on have had rigorous automatic testing. But we can always dream.
The fact that in real world projects you don’t know what bugs there until you test remains true, which was the point. I am sure you will find a way to disagree with that too.
Ok, now you are just twisting the meaning of your own words which no reasonable person would understand the way you are suggesting, take a look at what I initially quoted few posts above.
Back in the real world I’ve had 3 jobs in my career so far, first company was not a software company, just had a few in-house devs, there was pretty much no automated testing. The other two were built by software engineers and every single project was rigorously covered by multiple layers of automatic testing, it just wouldn’t get released otherwise. So it depends.
Oh I agree. But like I said most bugs can be caught with tests without any end user ever seeing the software. And it’s usually those bugs that are easily caught that are most glaring and make an impression of unprofessional software when users experience them.
Come on, you know the point of beta releases is to get wider test coverage. Even non-developers know that.
These side discussions get very pedantic, and non-constructive. It seem to be more about proving who is technically correct, than achieving a common understanding.
Yeah and you just keep ignoring the fact that I only responded to one specific point of yours and don’t disagree with you in general.
Anyway, it does get silly and derails the topic. Subject closed.
You mean that you guys get to release bug free software!? Nice!
It’s not easy to avoid all bugs, even with automated testing. But with a good test suite it’s definitely possible to avoid regressions. You shouldn’t need to ever “retest” a new release, once you encounter a bug, write a test case and it’s caught forever.
also, I personally was happy using nightlies until I heard that there was a possibility the new file format would have breaking changes that could be non-forward (not backward!) compatible. I think a commitment from the developers to avoid such a situation, (except perhaps in specific feature development branches) would help get more eyes on nightlies.
That’s new to me. Do you mean that file created by current Nightlies would be un-openable by later releases? Any sources? AFAIK there’s an unimplemented feature pending.
There’s no promise it won’t happen. IIRC it has happened maybe once. I vaguely remember one discussion where this was at least a possible reason for a user’s problem.
I think this is one good reason to announce a beta phase soon after the file format is stabilized and the last major features are roughly implemented, but before the rc phase. It would be a clear signal for those who need relative safety and combatibility but can stand bugs and occasional crashes. I’d guess it’s the majority of potential testers, at least if we think of more than occasional isolated new feature tryouts.
According to @craftyjon, the situation that the files could not be opened by future versions is “extremely unlikely”. So fingers crossed 
But indeed, unless Beta testing will be announced (with true “feature freeze”), 5.99 is not for the faint-hearted.
“Beware, dragons ahead”.
I quote Jon from another thread because the discussion was actually started here and doesn’t belong to that other thread:
Thanks for the feedback. I understand what you are saying. I’m very well aware of the catch 22. That’s why I have encouraged people to test and report early. However, I don’t see things being having been changes so much that it wouldn’t be easy to predict the same happens again. Therefore using ‘RC’ in the similar situation would just lead to a similar RC cycle again.
Announcing a beta or several betas might help a bit so that naming would be realistic, yet it could attract testers. Soon after the first big features have been merged (at least curved polygons which affect the file format) would be a good time to announce the first beta, which would also signal the end of the planned file format changes. If the version string is changed to for example 5.99.1-beta all nightly builds with that version could easily be identified as file format complete. Then, if ff-exceptions are still merged later, 5.99.2-beta would be announced. Especially python API freeze, if that comes, would be a good reason for a new beta. When there’s temptation to announce RC1 it should be resisted and the final beta announced – just because we can know for sure that new bugs will be found. Then the RC1 would be announced with a hope that no 5 RC’s and several months wouldn’t be needed anymore.
This way the version naming wouldn’t be arbitrary, it would actually communicate something meaningful in the development process, and at the same time might attract more testers. As we know, names and versions have psychological effects; meaningful versioning would give people something to grasp.
Is there a “not” missing there?
At the end of the day, whatever you call it the same amount of work has to be done.
No. Because the development/testing model hasn’t changed and the universe hasn’t changed since v5, we can be 100% sure that a big bunch of new bugs will be found after the next named version is announced. If it’s called RC we can be 100% sure that it can’t be expected to be released after only a couple of bug fixes and RC2; therefore the name RC won’t be appropriate.
Yes, approximately, and why not use more realistic naming then which can even have some positive effects? After all, it wouldn’t require any more work, right?
But I think this discourse has run its course without changing the universe. We are repeating the same things. I can only restate which I have said before in new ways. I think my arguments are well based and logical. So are yours. The basic difference is that you and the developers don’t care while I would be willing to try something new to see if it would make some difference (albeit small) for the wide audience and the project, and at the same time use words which would communicate the actual situation better.
When people start using ad homs like that, you know they have no logical argument.
It’s not an ad hominem argument. I just described your attitude towards the version names which is evident in what you have wrote. My attitude is different. I didn’t mean it to be derogatory. You have your reasons to not care and I don’t say they are bad.
Sorry, I don’t find a “lock” emoticon for this so I just say “this can be locked” and time to move on. I understand your point that in the end the version names don’t change much. V6 will be released anyway when it’s ready. There’s more heat than light here. Everyone has already formed their opinion by now.
EDIT: when I said “you don’t care” I meant only that you don’t care if it’s called RC or beta and therefore changing it seems to be futile in your opinion. I didn’t mean you don’t care about version names in general or don’t care about other things.
lol and you complain about “ad hominem”?
Well maybe I partly deserve it, but let’s not continue this any more.