Possible brown outs ?

How long ago have you had contact with PB?

May be it make sense to have a release from team repo, the wait for PB is indeterminate.

It sounds like you have the means to hide or dissuade users from accessing the current release. And to create a new release that will reduce confusion and serve everyone better. Call it something else if desired, release candidate, etc., but make it clear it's the current best starting place.

Add another tier to the process. Create something that roughly approximates a release. With the focus on stability and careful bug fixes. A shippable end product. Not new features.

I updated above "Release candidates" block with links to 3 found recently release discussion threads: www.deviationtx.com/forum/6-general-disc...-outs?start=20#44216

Please let's split / move upcoming basic release / handling / branch fixing / branch parallel (well-tested) development discussions (beyond the already answered technical issue) to one of the existing release threads or open a new thread.
This "Brown-out thread" feels to be the wrong thread for that....e.g future archive search?!

Thomas

The current online documentation is in better shape than the PDF that documents 4.0.1. I believe we were ready for a release last summer - the docs were up to date, all major bugs in the bug tracker had been dealt with, etc. The documentation is also more complete, as the process of moving to the current source format and updating it got some of the ini formats that aren't accessible from the Tx documented.

As noted, there haven't been a lot of new features actually committed since then - mostly it's been bug fixes and new protocols, and the authors of protocols have been good about updating the manual for those. We need to audit the manual and make sure that nothing new is missing (there's lots of stuff missing, but it was missing in the 4.0.1 release, so acceptable), as well as check for major bugs.

I think this should be dubbed 4.1, not 4.0.X. If it's a release candidate, then someone ought to backport the DSM fixes as suggested by Thomas to the 4.0 branch as 4.0.2, without removing the warning. If it's a release, then maybe not.

If we can get some input from PB, then it would be really nice to have documentation on his release process, so we could follow that. Similarly, knowing what the nightly build process is would help, even more so if we had access to the compilation results if the build failed.

Summary RLS testing / release candidates / short term suggestions: www.deviationtx.com/forum/6-general-disc...-outs?start=20#44216

For the archives and forum searching:
I added several DSMx questions about latest changes to the "DSM telemetry support thread":
www.deviationtx.com/forum/protocol-devel...port?start=400#46358