publishing an intermediate release 3.1.0?

EDIT: If you are interested in the actual preparing work for deviation 3.1.0 you can look in my repository at bitbucket here:
https://bitbucket.org/rbe2012/deviation-3.1
From time to time I update the dfu files in the download area so you don't have to create a complete build environment to help us testing (or if you are just curious).
Take a look at the open issues to see what still has to be done and at the commits to see what is already achieved.

_____________________________________________________

Original post:
There are questions from time to time if the deviation project has died. We all know that this is not the case, but the lasting absence of PhracturedBlue as the main programmer and above all decider leads to this estimation.
If PB remains invisible, can we publish an intermediate version like a 3.5.0 (half way to deviation 4)?
I personally am sure that the (still actual) nightly build has no real big issues from the point of stability. Many use them and no real problems are reported as far as I have seen.
We should discuss what would be necessary to do this and which code base will be taken. We could declare the actual nightly as a regular version (so discussion about the nightlies could stop at least) or use some other code.
I would offer mine ( deviation-rbe-bugfixing ), but somebody should also have a good base.
There are some issues left in the nightlies (PBs repo has a list of 49). Maybe some of them can be solved if we work hard but surely not all (but open issues were no problem in the past when releasing a new version...). Which issues must be handled before we could offer a new version with a clear conscience?
Another point: how to publish a new version? We can not change PBs repo and we probably can not change the method the nightlies are created and uploaded.

I feel a little bit disloyal and unfair to PB, but I think this step is necessary and virtually overdue. And I really want to see him back here and keeping to bring his knowledge to deviation as he has done for a long time.
As we all know deviation is mostly his baby and I do not want to take it away from him. So I think we should only make changes which we expect he would agree to.

It would be great if a new version supporting FBL100/V922 can be published officially ...

Well, after knowing that PB is very busy at this moment, I have downloaded and installed the latest nightly build in my Devo 8S. Just want to use the nightly build on my regular basis and see if there are any critical bugs. Seems the nightly build is more stable than the v3.0.0, and I have not encounter any reboots as in v3.0.0 when I copy and setup models.

I will continue to use the nightly build and see if it is stable anyway.

FDR wrote: To see clear, this is what I can do, and what I can't do:
- I don't have any access to PB's repo;
- I don't have FTP access to this site;
- so I can't effect the automatic nightly builds;
- but I have full site admin rights, so:
- I can post in the downloads section (however it won't match the repo state);
- I can edit any article, menu, forum, user, etc...

This is good to know. So we could change the "Home" page, post links to new versions on the download page (they should not be hidden somewhere in the forum) and write new release notes.

One important thing to do: update the documentation!
Volunteers needed...

Isn't a sticky on the builds sub-forum better ?

That type of release should only correct bugs, and maybe add latest protocol development... and 3.5 is a big step, maybe 3.1 ?

And maybe discuss the way to go with PB when he returns, should he be absent for a long period like now.

blackmoon wrote: Isn't a sticky on the builds sub-forum better ?

Good idea, but supplementary.

That type of release should only correct bugs...

It will be an update of 3.0.0, not of the nightlies. So the complete new GUI will be part of - a quite large step if you consider the changes in the firmware, the config files and the handling.
I have no preferences for the number - 3.1 seemed to me a little bit close and it should be far enough away from 4.0 so I proposed 3.5 as some sort of compromise...

And maybe discuss the way to go with PB when he returns, should he be absent for a long period like now.

Absolutely!

I agreed we need an next release and 3.5 works for me.

As part of the preparations we need to update the default model.ini file to support the new GUI features - perhaps update the main screen to add more bars - (Personally I add 2 more vertical bars linked to the 6 typical CP heli channels to do a quick pre-flight check of gyro gains and flight modes etc.)

The Devo12 users may also want a new main screen all together, making full use of their larger screen

Any suggestions?

Makes sense

I would be more than happy to look at the documentation and help with a rewrite.

I already posted somewhere else about the layouts that are currently underutilized. I would love to see all the GUI stuff out of the models and just a pointer to the correct layout like is done with icons. This way a layout could be done that includes all the screen available in one file and the model files become universal.

I have already started to look at the layout files when I ran into the problem that empty.ini only cleared Devos with color screens.

One thing I would love to see, is that all elements are available in all GUIs. This is a not so subtle plea for rbe2012 to bring back bigbox to the Devo7/10, please, please, please.

Guys,

If you do an update and a better GUI don't forget us plane flyers...

As the proposed imtermediate release is not meant to be so "offical", may be it is a good opportunity to incorporate the "two switch" feature into the 7e

cmPang

vlad_vy wrote: It wiil be nice addition, if not influence users without additional switches and it will be well documented.

Possible, we can have at tx.ini section [enhancements] with options to activate such nonstandard features.

I know it exists (and it is a quite popular mod) but I have no way to test it (no Devo7e here) so how can we make sure it does not influence those who didn't add switches?
Please point me to the right thread and the code and I will look at it.
Best would be to open an issue in my repo.
We (or only me via PM, don't remember well) have discussed that with PB. He was more than skeptical about such user-specific addons. His main argument was exchangeability of the model configs. It is hard enough to map the different switches between the different tx models - it will be worse if we allow individual switches.
If the 7e turns into a 10 only with adding some switches everything will be fine. But there are not enough switches to add with the method used (integrating them in the button matrix) so we virtually would invent a new tx model (considering the model files). The only way to keep this clear would be a fixed naming for those switches and a clear mapping when using such a model config in any other tx.

Another argument was that not every 7e will have the additional switches. How can we see if the switches are integrated if they are not active? There is no way to detect an open line inside the tx... So we have to store somewhere the information that this tx has the switches mod done. But where? In the tx.ini? Giving it to your buddy makes model configs possibly useless. Somewhere hidden? This can be only in the code - but we surely don't want two different deviation versions for 7e... The MCU offers a unique processor id and I managed to read it. This could be used to allow such an addon only get active when the id is stored in the tx.ini - giving the tx.ini to someone else will lead to ignoring of the addons. Something like:(I have integrated a vibration motor in my Devo8) Here could also be integrated the rf module mods (but it will do no harm if they are tried to use without having them built in... so they can also stay where they are).
But I am not sure if this number is really unique (or if I am reading the correct one). It is different between my 8 and 12 but a processor model id would fulfill that too... We should test this.
If it works we can also store individual calculation parameters for the power state (see isue #6 in my repo) without having to fear that the values will lead to a miscalculation if applied to a foreign tx by moving the tx.ini.

RBE, can you add to your fork all valid open issues from PB, and all enhancements from other users (protocols and etc.)?

I don't know how to do that (copying issues) other than manually. While cloning PBs repo I have not seen any option allowing to copy the issues. So this will be an annoying work...
I am not sure if I want to do this. I always believed when PB is back he pulls the 3.5.0-code into his main repo and we go on as usual. Copying all the issues will look like a replacement for PBs repo.

What do you mean with "valid issues"? Simply "open"?

About the user enhancements: I have no accurate overview about the enhancements done outside of the deviation tree. I know there are some protocol works like HiSky and Spektrum telemetry but I did not really follow the threads (again I have no way for testing nor using it so it was not of too much interest for me).
The best would be: clone my repo, add your enhancements and send me a pull request. This seems the easiest way for me to see how it integrates.

I have to tell all of you that I am really very far away from the brilliancy PhracturedBlue has shown while developing deviation. If this 3.5.0 will happen it has to be a common work of us.