Improve version numbering

[marsfan]

Looking around after being OOTL for a while on development, and I see three different versions of the firmware floating around the main thread on the DP Forums (specifically V7.0, V7.1, and V7.11). Furthermore, there are a number of confused posts about which version is a stable release. (See this post onward for an example).

USBEprom does a great job releasing a number of builds for us, but I believe that his calling of all builds as 7.1 adds confusion to this situation. Is there a way we can start referring to his builds as pre-releases and providing official release tags like we did here for V7.0? It should be as simple as adding tags in git.

Myself and a couple of other people have brought this up in the DP forums, but we have yet to ever receive a conclusive answer, the best (in my mind) being this post by USBEprom

If 7.1 is not out yet in any stable form, why have we had a changelog posted in the repo since September with commit ad67d5a.

I would be willing to help out with sorting this out, but I do not really know where to start with this at the moment.

[USBEprom]

@Marsfan

I totally agree, but sadly I know nothing about git and things like that. I numbering the firmware I build based on what shown by issuing command "i". For the latest two I got:

i Bus Pirate v3.5 Community Firmware v7.1 - goo.gl/gCzQnW [HiZ 1-WIRE UART I2C SPI 2WIRE 3WIRE KEYB LCD PIC DIO] Bootloader v4.5 DEVID:0x0447 REVID:0x3046 (24FJ64GA00 2 B8) http://dangerousprototypes.com HiZ>

I do not know how else to do. But if a way exists, please explain it to me and I will definitely land myself to it. Thanks.

[marsfan]

@USBEprom Here is a guide on creating releases for the GitHub repo. Only someone with editor right to the repo can do it, so you would need to talk to @agatti to get permission to write directly to the repo instead of making pull requests.

I feel it would be great for you to continue with these builds, and as this system allows builds to be marked as pre-release, it can keep everything organized and clear on the stability of the code.

As for the firmware, it is confusing, it would help to have something to clearly state if the build was from a stable commit, or a commit with unstable stuff being tested.

[Rondom]

I think the first step is to include git-describe-output into the built firmware :-)

I have already experimented with setting up continous-integration: https://circleci.com/gh/Rondom/Bus_Pirate/tree/simple-ci

Ideally we should come up with a sane set / sane sets of build configs i.e. features enabled.

Experimental changes in pull requests can also be tested by users who don't want to compile by getting the build artifacts from circleci.

Once this is working one could even automate the release-process whenever a tag is pushed, by creating a release on github automatically.

[USBEprom]

@all

While I was busy to be able to verify the overdrive mode of the 1-WIRE protocol with the Bus Pirate v3, I gave a look at the suggested links and tried to understand what to do, but not without great shame I must say that it is all stuff out of my ability, please apologize me. The thing that scares me the most is to do damage to the contents of the repository while I access it, so I would asperate in the most absolute way to put a hand and touch anything in there. Really sorry, but I am sure I would do serious damage if I could directly access the repository, because in all honesty I did not quite understand how the matter works. Very sorry guys.

[agatti]

This is going to become a mess quite soon, as DangerousPrototypes came up with a firmware version 8 without getting in touch with us, so I have no idea on how this can be improved in a long-term fashion (for reference: https://github.com/DangerousPrototypes/Bus_Pirate/tree/firmware_v8_official).

[marsfan]

@agatti Anything interesting added in that repo? I do not see much.

If you want to go full out cleaning this up, (in my opinion) you all need to get a line in with dangerous prototypes directly and try to fully merge our repositories. Looking here, It appears that the lack of communication is not really their fault and we might be able to work together with them.

If you want to try to keep a separate development thread going, you all are probably going to do the two following things.

1. Distance ourselves from their numbering. You need to focus on the community name, and reset our version numbering. (for example, maybe our next stable release be called BP-Community 1.0, or something of that sort).

2. Clean up our release plans. USBEprom does a great job with unstable builds, but they are the only releases you have right now. You need to start having fixed points of stable, and distributing pre-compiled hex binaries right here on Github using the release tagging feature. Look it over here, it took me about 10 minutes to figure it out.

To speed things up for development, these two might also help.

3. Add support for continuous integration. It will allow you to perform auto code checking, and automatically build hex binaries for every commit made to the repo. I have MPLAB installed, so I might be able to find some time to look into implementing that, but I have been pretty busy

4. Start keeping track of what edits they make, so you can pull and merge their changes, as well as potentially push your edits upstream to them.

I know this is kind of a dump and some of it re-hashing my original post on this issue, but this is the best advice I can suggest to avoid the potential mess that could develop from two groups leapfrogging with release numbers.

[Rondom]

Regarding 3 (continuous integration): I have already submitted a pull request #118.

There is a small issue (toolchain bug on Windows), which might need to be worked around. I kinda put working on this on hold until I hear back from @agatti on what he thinks and whether this work is welcome. In its current state, the binaries are compiled and can also be downloaded as artifact from circleci (for some time that is). As a next step one could generate a simple website with the list of builds from the job, but I think the current work is already a big improvement.

[marsfan]

@Rondom Cool. I was going to look into Travis-CI as I have used it before, but whatever works best.