Time for version 1.5.0

[bignose-debian]

Since the latest release, 1.4.1, there have been many bug fixes and some new features.

Please release a version 1.5.0 containing all the improvements since 1.4.1.

[Toxantron]

Would like to see a release too, maybe after merging #373.

[l0b0]

@Benjamin-Dobell Are you aware that you can assign other people as collaborators in the project settings? I'm sure there are plenty of contributors who would be willing to help out, especially if the license was a bit more free. People are practically screaming for new releases.

[Toxantron]

@l0b0 I think he knows that. However collaborators must be chosen wisely and that requires time he currently does not have.
Also for a version 1.5 the code needs some refactoring. As I figured out there are currently almost as many bootloader versions as there are devices. And thex have many different USB protocols. This is pretty much the reason for all those bug reports and pull requests. Even my fix worked on a Note 10.1 2014 LTE but failed on the WiFi version with the same Android version. If you look through the history you will see different changes to the USB protocol and eventually their coexistence became a problem.
A version 1.5 would need some sort of strategy or plugin architecture and a version selector, maybe combined with a device database. While I consider myself and especially the maintainer capable to do this, it would still require a lot of contributions because non of us has enough devices to test. While I love open source, I simply do not have the spare time when all I wanted was to flash CM on a tablet

[l0b0]

@Toxantron Thanks for the response. It doesn't seem to be possible to see who (if anybody) is marked as a collaborator. I would expect nobody, simply because it's been so long since the last commit (July 2016) and release (October 2015), and lots of open issues and pull requests. This is a popular project, and it would be great to see it driven forwards.

[Toxantron]

I totally agree and after fixing it for me I thought of trying to get involved more. Maybe if someone stepped up and "applied" for the position he would agree.

[Benjamin-Dobell]

Pull request have and will continue to be welcome. If suitable pull requests come through from the one person regularly then I'll happily make them a collaborator. However, as @Toxantron has explained the requirements for one device tend to conflict with another.

Also a lot (not all) of the pull requests are very hack/messy and it's clear the solution was arrived upon by trial and error (commented out code, changes that in theory are irrelevant etc.) That approach is fine, but if I'm not careful with code quality, this project will become a nightmare to maintain.

Other maintainers would probably close the pull requests when they're known to break compatibility (or don't match up with the project's code quality). However, I prefer to leave them open for exposure until I or someone else can come up with a better solution.

Making a release is also surprisingly time consuming due to all the Linux variants. I used Open Build Server in the past and found it pretty excruciating. A Mac build is a pain as you have to get your hands on old framework versions and do a lot of messing around in order to build a binary that will work on older versions of macOS / OS X. Even Windows isn't as straight forward as it ought to be.

[l0b0]

Great explanation, thanks! If you have the time, what would be your thoughts towards some ideas to perhaps make it easier to maintain:

• Using Java or an interpreted language to avoid the worst of the cross-platform issues
• Adding automated unit/integration tests and code coverage limits to improve quality
• Adding cyclomatic (and possibly other) complexity limits and linting to improve readability
• Using a FOSS license to attract volunteer developers

?

[Benjamin-Dobell]

Using Java or an interpreted language to avoid the worst of the cross-platform issues

C++ is cross-platform too, at least as far as the CLI goes.

Heimdall Frontend is also cross-platform thanks to Qt, but it's quite cumbersome. I started a complete rewrite (Heimdall 2) using Qt5 but it was painful. I think a much better solution is Node.js/Electron.

Adding automated unit/integration tests and code coverage limits to improve quality

I'm not a huge fan of unit tests, but integration tests for sure. I've been wanting to add "capture and replay" support for some time. I think I even have the very beginnings of it on a private branch on my computer (didn't get far). The idea would be that anyone can create a capture of their device being flashed. The capture would discard the actual contents of the firmware (for legal reasons, and cause they're potentially huge) then whenever changes are made to Heimdall the tests could run again and verify that Heimdall responds as expected to the device based upon the device's captured input.

The slight issue with this approach is that just because Heimdall responds differently doesn't necessarily mean the response is wrong. Devices are fairly tolerant and well accept a variety of inputs. However, it's at least a good starting point for knowing when the behaviour of Heimdall has changed and that at the very least regenerating "replays" is necessary.

The bigger issue is that I only have access to a very limited number of devices (Samsung release so many variants). So regenerating replays when behaviour does change would leave me totally reliant on contributors, which could really slow down the release cycle... Mind you the "release cycle" is non-existent right now, so... yeah.

Adding cyclomatic (and possibly other) complexity limits and linting to improve readability

Certainly not a bad idea, I'm admittedly well out of touch with the latest and greatest C++ tooling. The code-base in general could surely be simplified drastically by properly migrating to C++14 - again I'm a bit out of touch with modern C++ though. My experience with C++ stems from a game development background, but for the last 5 years I've been doing mobile, backend and some web development.

Using a FOSS license to attract volunteer developers

There already is one. The project is MIT licensed. I have no interest in less permissive licenses like the GPL.