publishing an intermediate release 3.1.0?

just to add little more info to 'extra' switch's. Devo 7e/10/12 and maybe devo6 button matrix do have 2 switch's not connected.

I agree with FDR enhancements should be stored in TX.ini, there no logic in sharing that file.

And a way of having the 2-2way or 1-3way switch enhancement for the 7E part of the trunk would be nice.

Even tough I was under the impression that the nightlies already had the 2-2way patch applied.

rbe2012 wrote: It will be an update of 3.0.0, not of the nightlies.

The nightlies seem more stable than 3.0.0, I would suggest that we "lock" the nightlies and call them 3.1

Then continue to work from there. Personally I have no problem just switching to RBE's bug fix repo.

PB's repo is safe from changes so we can always just go back to that. RBE, I'm not sure what state your Bug-fix repo is in. If you feel you would like to clean it up a little, then perhaps you use that repo as your "test" or QA repo, make a new fresh copy of the current PB repo and apply your fixes in a nice clean manner to that one.

That way, when/if PB returns he can just pull all the changes in.

Basically my concern in all this is that we don't have two different branches in the end. (Like ER9x and Open9x)

Basically I can agree too but there are some known issues like the 128x64-bigbox-problem (my #17) what can cause deviation to crash.
I personally would like to see at least #421 (crash if text is written outside the screen in Devo7e/10), #411 (Italian language file truncated), #404 (wrong scrollbar for toggle select) (all fixed in my repo), the Devo12 touch accuracy problem (improved), #360 and #389 (save last model)(not worked on it yet).

My proposal:
Clone PBs repo to "deviation-3.1", apply the fixes we have (or for which we agree that they must be included), rework the docu and publish this.

I agree, we publish it in the development forum as a Beta (or those that pull it from the new repo) for a week or so of testing before we then release V3.1.

blackmoon wrote:
...And a way of having the 2-2way or 1-3way switch enhancement for the 7E part of the trunk would be nice.....

yes, having an option of 2-2way or 1-3way switch enhancement is a great idea, sometimes we need a 3-way switch such as the recent Walkera QR X350 do..

cmPang

Ok. I have made the first step and cloned PhracturedBlue's repository into a new clean one called deviation-3.1 .

Please feel free to open issues for every bug we already know (from PBs or my old repo or which was discussed here in the forum) and which shall be solved before we publish the new version.
We will decide together which issues are essential.
I have understood that we will not integrate any new functionality in this first version, only the major bugfixing.

I will later post the issues for the bugs I mentioned above.

I accidentally forked the repo, until now I only cloned it. Will it be better to clone (easier to create pull requests for PB) or do we have advantages of a fork?
It looks quite the same in the bitbucket frontend.
Does anybody know which is better?
If we are not sure I will delete the fork and replace it with a clone.

BTW: I will clone/fork the deviation-manual repo too (if nobody else feels responsible...).

rbe2012 wrote: BTW: I will clone/fork the deviation-manual repo too (if nobody else feels responsible...).

I will clone your manual repo, I don't think I should own it since I will likely need to ask a lot of questions about how and why certain things were implemented the way they are to make the documentation clearer.

I do have a lot of experience writing "white papers" and case studies in a former life so I am more than happy to help with the documentation.

WheresWaldo,
great that you will care about the docu. May I ask if you are native English speaker? I think this is not necessary but helpful.
Your experience is really welcome.
My docu-repo is here: deviation-modelconfig-manual . We started to work on a docu for the model config, but is not ready yet. The rest is originally the version as it is in PBs repo.
The format of the text is something special. I have to look, but I believe it was a LibreOffice format bgood to use for version control systems. I must repair my other pc, it is installed there.
But it is written somewhere in the forum...

The format is called "fodt".

rbe2012 wrote: WheresWaldo,
great that you will care about the docu. May I ask if you are native English speaker? I think this is not necessary but helpful.
Your experience is really welcome.
My docu-repo is here: deviation-modelconfig-manual . We started to work on a docu for the model config, but is not ready yet. The rest is originally the version as it is in PBs repo.
The format of the text is something special. I have to look, but I believe it was a LibreOffice format bgood to use for version control systems. I must repair my other pc, it is installed there.
But it is written somewhere in the forum...

Native english speaker. I will likely use whatever tools I have already installed and then convert it to LibreOffice format before commit. I am assuming "fodt" is some sort of linux format, I will google it.

Found it: Flat OpenOffice Document, basically a flat xml file, I will look at the source as soon as I get my file server up and running. Probably tomorrow.

I have changed the title of this thread to reflect the "3.1.0".
I also started transferring the issues which should be solved.

rbe2012 wrote: I have understood that we will not integrate any new functionality in this first version, only the major bugfixing.

I will later post the issues for the bugs I mentioned above.

I know you said the above but, may I ask that the new Hisky protocol is integrated in this revision ?

A patch is already available here :

Protocol name Hisky

www.deviationtx.com/forum/protocol-devel...tocol?start=80#14686

Even tough it isn't 100% tested, it is mature enough as some people are using it without any major issue.

When we decided not to add any new functionality in the 3.1.0 we had good reasons. Two of the more important are: we don't want to open another matter altogether which could result in issues redounding on to the complete deviation-3.1.0 although they are only new-feature-related. The second is that we don't want to move in a direction PhracturedBlue can not ratify without knowing about his plans.

I will spend some relevant time in working for 3.1.0 in the next days. I will take care that the 3.1.0-repo-changes will be mirrored to my old bugfixing repo. I will try to integrate the HiSky-protocol to this repo later so I can post easily builds with the new protocol. But give me some time for this.
Maybe later this will be included in the main code...

After my post, I thought about it and you're right integrating new things could lead to issues.

Integrating the HiSky protocol and other things, later would be nice to.

And thanks for the time you'll put into this unofficial release.

It's good to see some skilled people who care, take the time to polish this great firmware.