search

zs6buj / mav2pt

Mavlink to FrSky Passthrough protocol telemetry
GNU General Public License v3.0
120 stars 47 forks source link

Tags for various versions, improved tracking of changes between versions #63

Closed rotorman closed 3 years ago

rotorman commented 3 years ago

Dear Eric, I noticed that every new version you push here is created in a new folder and then the old version is moved to archive subfolder. This makes tracking the changes between the versions (even minor versions) more challenging than IMHO it should be on GitHub. An idea to avoid this, would be for example to skip the version number in the *.ino filename and use GitHub tags for various releases. Would you find that a good idea?

zs6buj commented 3 years ago

Hi Risto, I've been meaning to try tags, but I currently use the binary name, which includes the version number, in my logs. When a user appeals for help and presents a runtime log, I know exactly which version to look at.

Any ideas? I could maintain a version constant in the change log in config.h. but maybe there is a better way.

rotorman commented 3 years ago

Hi Eric, I believe, a define in a file, as you suggest, is the std. way of including version# in a code that could be included in a log.

I would suggest to create a v(major)-dev branch, where the development for v(major) happens. Whenever the code there is worthy of a new minor release, a tag can be created (=pointer to a state in history) of that state and a name (e.g. version number, like release/v(major).(minor) is given to it. One could additionally do release/v(major)latest tag and update this along the way, to be able to give users a single link for always getting the latest of v(major). A filename should IMHO not include a minor version, as this makes tracking changes more difficult as it should be (for major version this would be OK, thus e.g. _MavToPassv(major).ino, whereas MavToPass.ino would likely work just fine).

Whenever time is ready for starting development of v(major+1), a new branch with v(major+1)-dev can be created. When it is mature enough to be used, the default branch could be switched to v(major+1)-dev.

Using branching and tagging and committing minor versions into existing locations and files, allows much nicer options to view or review the changes in each commit or minor revision.

Best, Risto

zs6buj commented 3 years ago

Agreed. I also have an issue with redundancy. For example, all pPlaformIO builds have a library folder, containing some large libraries, and they are duplicated for each build.

Maybe this is a good time to sort it out.

rotorman commented 3 years ago

Awesome, thanks!