As GC and firmware versions go together is there a way to rollback the GC version if an update turns out to break things, and people want to go back to their previous working version.
Or should an older firmware be enough?
also for this reason it eventually would make sense if GC could upload the matching firmware to the Arduino
you would need to roll back both, just grab the old version and replace the
current one the same way you would do an upgrade (if you are using git to
populate things, checkout a specific version tag instead of the newest version)
The releases pages for both GC and Firmware list previous versions. If you’re troubleshooting, you should probably roll both back together until you find a combination that doesn’t have the issue you’re investigating, then look at what changed in each subsequent release to try to narrow the source down.
You should write a script to backup the GC directory , before making changes, forward or backward.
Thank you
Is a backup necessary in this instance? The previous version links will bring folders with their version number in their name; they shouldn’t overwrite subsequent versions, yes?
It should include your .ini and is always a good practice. Good habits lead to good results.
Thank you
I believe the .ini file is in the user’s home directory, not in the GC directory. Is that not so on Linux?
I’ll have to investigate. As a backup script it should round it all up and package it. I appreciate you pointing it out.
Thank you
I see, this is a bit more complicated as I had in mind.
I forgot to mention that this is for my VM
I’m trying to figure out a way how to accomplish this on my VM Ubuntu build.
The goal is to make it easy enough for everyone to use.
Upgrading is simple enough, but if a user gets into trouble after an upgrade then rolling back will be a struggle. Specially for people who never used Linux.
For me the extra obstacle is maintainabillity of the VM… If it is not easy to maintain then it will fail since users then need support, and i don’t have time for that on top of maintainance.
My apologies for not mentioning that this was for the VM.
Also i try to do this 100% from git if that can be done.
And slowly i see myself drowning in all this. And i’m barely getting started.
Maybe i have to re-think this VM, or just wait for a real installer.
Another question.
Is it possible to use git to install a specific version.
Say, 0.98 worked good for user X. Is it then possible to clone 0.98 from git?
This is still early stages so maybe i want far to much at this point in time. 
This is why you would want a set of scripts. You do the work and point the users at the scripts.
Thank you
Rolling back doesn’t need to be a struggle. Each new release comes in its own folder, with the release number in the name. To use v0.98, you cd into folder GroundControl-0.98 and do the ‘python main.py’ thing. If you want to script it, get your script to list all the folders like ‘GroundControl-v*’ and let the user choose which one to run.
Hmmm ok thats sounds good!
Any idea how that works with Git?
If you use the Git Releases page to download the ‘Source code (.zip)’ for each release as your update method, you’ll have the folder structures I’m describing. If you’re using the git command line executable, the process is more complicated and probably not the easy kind of thing you’re looking for.
I used
git clone
I see there is a .dmg for mack users, would it be an option to have a .deb as well?
To me a .deb makes more sense then .dmg. As i would hesitate to put a mac in a dusty workshop.
On a distro users should not be manually downloading stuff. I want to keep the commandline involved a bit, so that new users get a taste of that, still i try to install direct from a repository to make sure that everything ends up in the right place.
the winmac style of manually download a package ‘somewhere’ and then install it ‘one way or another’ looses against
install _package_ from <URL>
the latter provides some consistency.
I just have to be carefull that i keep time available to learn all the Maslow stuff myself. If I need to spend all my time on building a distro then i never get to use the Maslow. …
you clone via the normal process, then go to the directory and do
git checkout v0.98
and you will now have v0.98 there. Just don’t do a git pull after that until you
are ready to move to the most current version.
Please don’t do this.
use git to clone the repository and git pull to get newer versions.
Then you have every version ever and can just use git checkout to get the
version you want.
By the time you download two zip releases, you will have used more bandwith than
using git to download every version ever.
Bandwidth or simplicity, it’s a choice. How would you script saving and presenting a reference for previous releases so a less confident user could move back to a previous version?
But that is a bit problematic… A user needs to try this and be able to roll back if it fails.
I’ll read up on the checkout command.
Sorry, you’ve already answered my question. Reading on a cell phone really is sub-optimal.
I can’t help but think that i’m having the wrong approach somehow.
git is dev tinkering
but end users need stuff that is no longer in the dev domain.
bleeding edge needs a lot of first aid.
I should be running real releases only and stay away from bleeding edge somehow, also with safety in mind…
I’m listening to a git tutorial right now to see if i can get my head around that checkout command.