Discussion: Release process

[emilecantin]

I'd like to start a discussion regarding the release process. I know we currently use the even=stable, odd=experimental convention, but is there a reason why all of them are marked as "pre-release"?

I think it'd be way easier to actually use that pre-release feature for experimental releases. That way, we could promote experimental features to stable once they've been tested; no need to cut an additional release.

It'd also make it easier to consume the list of releases from a script. I'll probably need this as I improve on the RPI image build.

[Orob-Maslow]

Perhaps it is a matter of definition. Only at 0.932 did the even odd thing start. I understand release to mean good for the general population while prerelease is not fully vetted... However rigorous that is. What would be a better description that should be used? At what point does it move to 1.0?

[emilecantin]

No, I think that description is fine. It's just that when you go on the Releases page, everything there is labelled "pre-release", which is the default value for that flag. I think we should make use of that flag, instead of layering our own convention on top of it.

[Orob-Maslow]

Agree. Even or odd, if stable, it should be a release. If testing new or specialized features, then prerelease... is there also a major/minor release approach?

[madgrizzle]

I'm open to any option that works and prefer the "correct" way, whatever that is.

It was easy to implement the even-odd thing to solve the problem of releasing a release that breaks webcontrol.. including upgrade/downgrade. I wanted to make it so people could opt-in to testing and those that just want stability, don't even see releases that are not "tested".

As for the pre-release tag, I just never used it.. nothing against it.

[emilecantin]

As of right now, all the releases are marked as "pre-release". I think it wouldn't be too hard to go through them and remove the "pre-release" flag on the stable ones, as a first step.

The "isExperimental" method in the update code could then be updated to look at the prerelease flag instead of parsing the version number, and that would bring us to the exact behaviour we have today.

The main differences would be that it'd then be possible to "promote" a release as stable (or not, no obligation), and it'd be a bit clearer for people browsing the releases page what's what.

[madgrizzle]

Is there any real reason to keep all the old releases?

[emilecantin]

Not many. You mentioned the downgrade possibility earlier, and it could also help pinpoint when a possible regression was introduced.

Having the history that goes with the releases (the description of the changes on each release) is very valuable, though. I refer to it all the time in other open-source projects.

I don't think it's a significant cost to keep them, so I don't really see a great reason to get rid of them.

[madgrizzle]

I was just thinking of ease of moving forward using pre-release tag, but I'm sure we could just add another conditional to make sure the version number is greater than 0.9335 (or whatever) before tagging it in the release manager as an "experimental".

[emilecantin]

Not sure why you'd need to do that. What I had in mind was pre-release === experimental. No need to parse the version number or anything. The only prerequisite would be to manually go into the old releases and correct the flag for all of them. There's only 18 releases right now; shouldn't take very long. I can do it myself if you give me access.

[madgrizzle]

I went ahead and fixed it.

Regardless, you are a member of the organization, but don't have access to the WebControl repo, correct? When I brought the repo over, it brought over all the collaborators as well (which you weren't one of, I guess). Do I need to specifically add you to the WebControl repo? Or do we need to create a team or something for the organization? I'm new to all this.

[emilecantin]

Awesome, thank you.

And yes, that's right; I only have read access to the repo, and no, I wasn't a collaborator before (just now getting involved in this). I think creating a team would be the best approach for this.

[madgrizzle]

I'm creating a final release on the madgrizzle repo marked as stable (0.94, even digit). I did a PR to pull in all changes from my fork into this repo so they should be identical. I'd like to get the same release up on this repo as well and will work on modifying my build scripts to build and publish here. However, I'd like to discuss if there are alternative ways to do the builds.

Right now I build for RPI, linux, Win32 and Win64. The RPI build runs on a dedicated RPI. The Win64 build runs on a win64 computer and the linux and Win32 builds run in VMs on that same win64 computer. The linux machine builds the firmwares and then makes them available on its ftp server for the RPI, Win32, and Win64 machines to download them (so they don't have to build the firmwares). I don't launch the RPI, Win32, or Win64 build scripts until the linux build script has finished with the firmware compilations. After all the builds are completed, each machine uploads them via FTP to the linux machine's "release" directory. On the linux machine, I then run a script that creates a github release and uploads the builds. Finally, I edit the release via web to add a title and description.

Any idea on ways to improve this or maybe, possibly, put it all in the cloud? The builds are pyinstaller based. I'm not sure if there's a way to cross-compile, etc. so it runs on just one machine. Or do we need to maintain VMs and if so, is there a VM for an RPI?

[emilecantin]

I think the first step here would be to actually publish these scripts, so people could build releases on their own.

Then, we could look at integrating a continuous integration tool (like TravisCI); there are a handful out there that are free for open-source projects. This would be a "cloud build", in your words. They're usually able to build in a few different environments, Travis even has macOS environments available.

I'm not really familiar with pyinstaller, so I'm not sure what it actually needs to build natively; unless you wrote some native code yourself as part of WebControl, we can probably get away with just downloading pre-built versions of every dependency.

Compiling software for the Raspberry Pi is something that's pretty common; depending on our specific needs (again, need to research pyinstaller) we may have many options here. Worst case scenario would be to move all the dependency management to the pre-built image, might make things a lot simpler from the WebControl side.

For the firmware build, I think that should actually live under the firmware's repos; the release script would only download the latest release binary from the firmware repo directly. That might not be possible, however, as we might not have control over all versions (notably the stock one); in these cases I think we should either maintain a fork that has the CI integration, or put in a pull request for that to Bar so we can pull from the "true" source.

[madgrizzle]

I think the first step here would be to actually publish these scripts, so people could build releases on their own.

The .spec files to build the pyinstaller releases are already part of the repo. main.spec is the spec file for the singlefile variant and main-onedir.spec is for the singledirectory variant. I use the same spec files for each architecture and it seems to ignore the architecture-specific adds in them. The user will have to adjust the pathex within the file to make it work on their installation, but that should be simple enough to do.

What I haven't pushed is the scripts I used to semi-automate the process. That's because its specific to how my build environment is and secondary that it includes things like FTP passwords and such.

For the firmware build, I think that should actually live under the firmware's repos; the release script would only download the latest release binary from the firmware repo directly.

This is the challenge because the last release was nearly a year and a half ago. Only bar can make the releases, afaik.

in these cases I think we should either maintain a fork that has the CI integration, or put in a pull request for that to Bar so we can pull from the "true" source.

I really would like to see a single firmware that has both triangular calibration (i.e, stock) and holey calibration contained in one. If we do this, then I think we can convince bar to make it the official release if we demonstrate that it also works with ground control, which knows nothing of holey calibration. It's not impossible, or even hard, but its not trivial and will take time and testing.

[madgrizzle]

I'm not really familiar with pyinstaller, so I'm not sure what it actually needs to build natively; unless you wrote some native code yourself as part of WebControl, we can probably get away with just downloading pre-built versions of every dependency.

Afaik, you need a complete installation with all dependents installed on each architecture, to the extent that the program can actually run, in order to use pyinstaller to compile the program. I'm not sure how all this can be done in the cloud. Travis-CI is completely new to me. I understand what it does, but how to set it up is way beyond me.