Is a Deviation v4.1 release on the near horizon?

Just curious if there is a rough idea on when a new version of Deviation might be released. Is it, perhaps, waiting on the completion of the single-board universal module, and any de-bugging associated with that project?

I would assume that the older multi-module build will be supported by any such release. Would that be a correct assumption?

Thanks for the update.

Wish I could help with some of those things, ....but I am a mere mortal, not a code warrior.

I appreciate all of the talented people that make this all possible!

I was about to reject the toggle selection pull request. The last set of updates didn't merge cleanly, and I'm not sure that it can be made small enough to fit on the 7E.

There is one fix in it that needs to be incorporated no matter what. The symbolicon array in the b&w displays overflows. That's in toggle_select.c, but doesn't seem to happen in the color version. Let me know if you'd like a pull request just for it.

FWIW, I think that it's been long enough between releases that we should do a release ASAP, leaving out anything non-trivial that's pending and not ready or we're not sure how to deal with, like my toggle icon code.

And as a last note, the toggle icon code breaks backwards compatibility. It will load old model files, but old firmware won't load the ones it's written. I think that calls for a major version bump.

I'd put a +1 on doing a 4.1 release with what's available now...

It's been a long time since the official release, and the current nightly are much better than release.But there are folks who prefer to install the stable version, not nightly. If all the tasks that PhracturedBlue mentions are "a few months away", that means that between 4.0.1 and 4.1 more than 2 years would elapse... 18 months seem a good interval between releases (4.0.1 released in Jan 2014), so it seems that 4.1 is due...

Having said that, I'm happy with the nightly...

Just call it 4.0.2 and release it

Any chance of getting a road map for what you need for release (other than documentation and issue checking) so that others can work on it? Or is that the list?

For the switch code, any chance we can make the UI load dynamically on the 7E? Or large chunks of it, anyway? That would free up a lot of space.

Back on topic. Can I play release manager?

It sounds like we're actually not that far from a "release what we have" type thing, then. If we leave out the stuff that you've already said is experimental, there are three things on the list: The new DSM/telemetry code, my toggle code and hexfet's "text select" feature. If the Joysway protocol checks out, I'd like that merged . I'm not sure what the last one is, but I believe a release without the first two would be fine, as they aren't in the release right now. I'm perfectly willing to do a bug triage and see where we stand on things. A code freeze on the default branch while I do that would be appreciated.

The other issue is the manual. I'd like to revisit a format change. Not for reasons doing with tool-chain or religious preferences or whatnot, but just so that we can get a version that can be merged. For now, is the version in the deviationtx/devaiation-manual repository the one we should be working on? If so, I'll see if we can get some help with it.

I have no problem with holding off my toggle icon code. It changes the file format, so needs to be handled carefully above and beyond the issues with the 7e.

Any chance we could get products in Mantis? At a minimum, the ability to pull out web site stuff would help a little. Transmitter tags would also help, especially if it allowed multiple tags, or at least an "any" tag. For instance, I'm not sure of the status of the F7, but I suspect iI can't do anything about the crash report for it in any case.

I agree about markdown, it's really not suitable for even a complicated web page, much less a user manual. I don't worry much about formatting these days - I've never found anything short of something like FrameMaker I was happy with but TeX, and that's a pretty hefty install. Especially if you also want a GUI.

Any objections to google docs? That's what I wound up with when I wrote the model config tutorial, but I didn't worry much about formatting. Pluses are zero-effort install, built in revision tracking, shared editing, and it's easy for anyone to suggest changes. Downside is that you either let anyone edit it, or require a google account to edit. If you don't have a problem with it, I'll try converting part of the manual so you can check out the formatting.

Ah, "platform" is perfect. I just saw product and figured that was where such should be, and it was empty.

Except there aren't enough of Platforms. It doesn't even list all the current supported transmitters. Can we add:

Devo 6/6S.
Web.
Entries for the unreleased Tx's available in the nightly build. Either an "unreleased" platform, or one for each of them.
Multimodule.
Universal module (since there's code in the nightly for it as well).

I'll try and convert some sample chapters to google docs. Probably a simple one, just to see if the basic formatting can work, and then something more complicated as well.

I'm not an IT expert, just wanted to throw in WinDiff as an Open Source file/text comparison tool with Windows GUI. Maybe this could help in the proof reading of versioned up documentation files...

Ok, I've gone through all the open issues.

Serious outstanding issues :

Most of the issues are DSM/Devo telemetry related. I've reached out to Indigo about his fixes.

A lot of the rest seem to be related to channel ordering being wrong: Users changing to DSM protocols and the model not following, so they get odd behavior, and possibly fix it by changing Tx modes. This may need further investigation.

There were major bugs about the RX1002 not binding to Deviation. I've asked for help with those: deviationtx.com/forum/7-development/4422...02-not-binding#33610

There is a bug with the V323 assigned to victzh that still needs to be worked out.

Finally, PB needs to look at a report about the Devo12 not creating an errors.txt file.

Details on what I did

I went through pretty much all the issues, and did the following:

• Asked for feedback on any that weren't clear
• Closed any I could easily verify were fixed or user error
• Closed any duplicates, adding reference to the other issue
• Assigned remaining old issues to me and requested feedback
• Changed everything else from new to acknowledged

Many of the old issues don't have a reporter, so we may not get any feedback. I've asked for help on these issues: deviationtx.com/forum/7-development/4421...on-bug-reports#33609

Summary of open issues

62 open issus

• 18 feature requests
• 15 minor bugs
  • 7 awaiting feedback
  • 2 manual isses (assigned to me)
  • 1 DSM telemetry issue (fixed in Indigo's DSM branch, assigned to Indigo)
  • 2 random issues assigned to Indigo
  • 1 from me, can wait.
  • 2 misc. assigned to me for confirmation.
• 25 major bug
  • 14 awaiting feedback
  • 4 DSM/DEVO telemetry issues assigend to indigo1
  • 2 are manual fixes, assigned to me
  • 2 CC2500 issues assigned to me
  • 2 NRF24L01 issues assigned to victzh (both created by me)
  • 1 Devo12 issue with errors.txt not being generated, assigned to PB
• 4 crash bugs (all assigned to me)
  • 3 awaiting feedback
  • 1 CC2500/Skyartec issue

About the manual, I already talked about it, but you can really have some great output from a RST source. Take a look a the Symfony2 manual for example:
symfony.com/pdf/Symfony_book_2.7.pdf

I understand that it would come with a big cost for the non-techie contributor, but it would help so much, even for the diff between platform as the source is just text.

Moreover, it can be translated to a nice website:
symfony.com/doc/2.7/book/http_fundamentals.html

The source code looks like that:
raw.githubusercontent.com/symfony/symfon...ttp_fundamentals.rst