Deviation v5.0.0 build with latest protocols

Hey guys isn't it time to launch a 5.1 ?

I think we can safely state you must fly the nightlybuild and not anymore use the default 5.0.0.
Or maybe time when the voice mod and documentation are ready?

The problem with the nightly isn't that it isn't stable, it's that there's no presumption of any kind that it will STAY that way. So the last N may have been fine, but the next one could be an utter disaster. Which is why my recommendation to anyone having problems with a nightly is going to be "go back to either the release or Vlad's build".

And yeah, Vlad does these builds because he dislikes the new UI. That he makes them available to the rest of us is a great service. Because we really, REALLY need a build between the nightly and the release. It needs new protocols - which are the primary reason people use the nightly builds - along with some guarantee of stability. Exactly what the latter is doesn't matter, just so we don't have code that may not have been tested by anyone but the developer showing up in the next build.

I've been bitching about this since before 5.0 was released - or before that release process was even started. The only thing that's changed since then is Vlad doing that kind of release, which as far as I'm concerned just shows how badly we need it, no matter why he's doing it.

Why cannot there be more frequent releases? I have been using Deviation since 2013 and I am still not quite sure why.

I agree that whatever vlads reasons are for doing these builds the fact that he is doing it is a great service. Keep up the great work vlad. I appreciate your time and efforts.

Indeed it is great work here!!

What confuses me is that we speak about new updated versions of 5.0.0, but if we update versions why we not change the release nr each version, so we keep track of versions?

Fernandez wrote: Indeed it is great work here!!

What confuses me is that we speak about new updated versions of 5.0.0, but if we update versions why we not change the release nr each version, so we keep track of versions?

We only have two kinds of official releases. The nightly builds happen once a day if there was a change, no matter what state the software is in. There's no requirements for testing or manual updates or anything else. They're alpha test software, and should really only be used for testing, meaning you're prepared for catastrophic, aircraft-terminating failures when you go to a new vesion. They're also ephemeral - we keep three of them around, and after that they vanish. So there are no release numbers, just the commit number for the source they were built from. That's enough to recreate them if we really need them. For what they are, this is fine. I'd like for the version number in the build to include the next expected release number instead of the last one, but that's minor thing.

The "release" version has a pre-release period for testing and fixing bugs, updating the manual, etc. It doesn't happen very often, but we do get new release nr's when they do. It represents several months of work. It's for users new to RC, or deviation, or open source, and want a traditional release. I'm not sure we're ready to start it: a new release should pick up the new F series transmitters and the new UI, and I don't know if those have been adequately tested yet. And the voice alerts code just got into the nightly, and I know that's not been adequately tested.

If you look at those two groups, there's an obvious problem. Most of our users don't really want to use an "updates can fail catastrophically" release, but on the other hand are new to things only briefly. Which is why many open source projects incorporate a third level in between those two, providing a version that includes some tests to help avoid major breakage. Typically, it incorporates changes from the fastest moving build after they've been available for a while and nobody has reported a problem, possibly there's a requirement that the changes be documented or not require documentation changes, etc.

Yes I understand the issue, and we should have some kind of major releases and some kind of test versions in between.


But for me the question is more how to keep better track of releases nigtlies and test build, sometimes is just not so clear.

Taking for instance other projects such as betaflight, the version nr just increases, and in the end it is up to you to load the very latest version to be part of somehow testing and reportjng or to go for a "more proven" version but somewhat older.
Then the software grow and some expiriments features in software may be removed added etc.

At least when people report give feedback etc it is more clear what version etc they run, as deviation have so many nightlies that Is not very obvious.

Well, if they give us the full version number - with the commit number - then we know exactly what they are running. That the number doesn't increase means you have to have the sources handy to figure out which version is newer, but that really shouldn't matter. If you're using the nightly for what they were meant for - testing and previews - there's no reason to ever be using anything but the latest one. So you update to the latest version before reporting an issue or whatever.

In other words, I think the problem goes away if we have that intermediate build.

Maybe. Not to the same degree as a full release in any case. It depends on exactly what they are.

For instance, I'd restrict them to new protocols and bug fixes. The bug fixes shouldn't need documentation as they generally make the code match the documentation, and new protocols that don't have documentation don't get included. So no documentation work is needed.

As for testing, changes should only come from the development branch. They get moved to the intermediate build branch after they've been in use for some period of time, and that's your testing.

This would also make doing releases saner. Instead of having to do the testing and documentation from scratch for everything when you want to do a release, you can cherry pick new features that are ready for release and merge them into the intermediates branch for more thorough testing after 's they are documented. When you're happy you've got all such changes in and testing is finished, you change the version number and build a release from the code you've been using.

FDR wrote:

mwm wrote: As for testing, changes should only come from the development branch. They get moved to the intermediate build branch after they've been in use for some period of time, and that's your testing.

Yeah, but here lies the problem, that we don't know, if those bug fixes and protocols were properly tested in the development (or master) branch. More likely they won't be, if there was an intermediate build, which is supposed to be more stable, so we would suggest to use that instead of the nightly builds. This way the nightly builds won't be tested, just like the test builds most of the times...

But actually Vlad's build do almost exactly what you have described, but honestly they are not tested either...

But there's no promise of "proper testing" on the intermediate builds, It is not a release. The real stability improvement isn't from better testing, though ideally we do get some of that. It's more stable because it doesn't get new features, which are the changes most likely to break things.

That said, we do want people to test the nightly build. So the delay between something showing up in a nightly build and being merged into the intermediate build needs to be set long enough to allow that to happen, but short enough that most people won't be using the nightly build just to get new features.

This does bring up a question I've never gotten an answer to. What is"proper testing" for a release? I haven't seen anything beyond throwing it out and seeing if anyone complains.