- Posts: 1433
publishing an intermediate release 3.1.0?
- rbe2012
- Topic Author
- Offline
- So much to do, so little time...
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.
- vlad_vy
- Offline
- Posts: 3333
rbe2012 wrote: 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.
You (or someone) can publish new unofficial intermediate release at 'Builds' forum. But I think this way havn't the future.
- SeByDocKy
- Offline
- Posts: 1016
- FDR
- Offline
- 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...
- richardclli
- Offline
- Posts: 199
I will continue to use the nightly build and see if it is stable anyway.
- rbe2012
- Topic Author
- Offline
- So much to do, so little time...
- Posts: 1433
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.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...
One important thing to do: update the documentation!
Volunteers needed...
- FDR
- Offline
Yes.rbe2012 wrote: 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.
- FDR
- Offline
I would leave that for someone with better english...rbe2012 wrote: One important thing to do: update the documentation!
Volunteers needed...
- blackmoon
- Offline
- Posts: 402
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.
- rbe2012
- Topic Author
- Offline
- So much to do, so little time...
- Posts: 1433
Good idea, but supplementary.blackmoon wrote: Isn't a sticky on the builds sub-forum better ?
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.That type of release should only correct bugs...
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...
Absolutely!And maybe discuss the way to go with PB when he returns, should he be absent for a long period like now.
- RandMental
- Offline
- Posts: 521
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?
- FDR
- Offline
EDIT: ...and from all the empty modelXX.ini files too, of course...
- RandMental
- Offline
- Posts: 521
- WheresWaldo
- Offline
- Posts: 253
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.
- vlad_vy
- Offline
- Posts: 3333
FDR wrote: I would delete all the gui sections from the models/default.ini, so the default layout (layout/default.ini) could be used...
EDIT: ...and from all the empty modelXX.ini files too, of course...
In Nightly Builds it's already done.
- Essen1
- Offline
- Posts: 64
If you do an update and a better GUI don't forget us plane flyers...
- cmpang
- Offline
- Posts: 296
cmPang
- vlad_vy
- Offline
- Posts: 3333
Possible, we can have at tx.ini section [enhancements] with options to activate such nonstandard features.
RBE, can you add to your fork all valid open issues from PB, and all enhancements from other users (protocols and etc.)?
- rbe2012
- Topic Author
- Offline
- So much to do, so little time...
- Posts: 1433
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?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.
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:
[enhancements]
txid=56789acb
switchmod=1
vibratingmod=1
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.
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...RBE, can you add to your fork all valid open issues from PB, and all enhancements from other users (protocols and etc.)?
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.
- FDR
- Offline
The tx.ini is already tx specific. For example there are the stick and screen calibration values. People shouldn't share or exchange tx.ini's...
I agree, that the additional switches should have fixed names, however it is possible to add 2 two state switches or 1 three state switch, so we rather should list the valid switch states (like MIX0+MIX1+DR0+DR1 OR MIX0+MIX1+MIX2), and then assign them to the line they use...
Then when loading a model config, the conversion should look if there are additional switches defined, and and convert them accordingly. Sure it will be more complex, then without...
- Home
- Forum
- Development
- Development
- publishing an intermediate release 3.1.0?