Release management

I have been following the release of Arducopter 2.0.x.There are few things I have noticed that I think should be fixed for better tracking of bugs and better release management.1) Libraries in svn are shared between many distinct projects.a) This implieas that there are libraries kept around that have nothing to do with particular project.b) Libraries in release zip files are collected in some ad-hoc manner into the release zip file.c) Release zip file has not 1:1 mapping with code repository (svn).Fix : Keep the libraries with the project and use merge feature of svn to merge libraries between projects when appropriate. Instead of having the directory layout,trunk/projectA/projectB/libraries_for_A_and_B/use the layout,trunk/projectA/Application/libraries_for_A/projectB/Application/libraries_for_B/2) Versioning is wild. I mentioned this is another thread/blog and there has been improvement. Still I am seeing snap shots beeing changed but version kept the same.a) This has the potential of infinite confusion, e.g.A : I have a bug.B : Which version are you running?A : I am running 2.0.20.B : Did you download it yesterday or today?and so forth.What I am trying to say there can be two (or more) releases with the same version number, one with a particular bug, another without it. Very confusing and only making harder for the developers.Fix : Increase version numbers frequently. It is better to have the same release with two different version numbers, than two different releases with same version number. If in doubt increase version.3) File names are case sensitives. But some zip files drop all case sensitive names.a) This is maybe a minor thing when building from Arduinu environment, but if building with other methods this is a problem.b) Also a big problem if people are merging you releases into their own code repositories.Fix : Decide if file names are case sensitive or not, and stick to that convention.4) Distributing .svn files with the zip is a very bad practice.a) Some of the zip files contain .svn folders and other "hidden" files that should not be distributed with the release. It will makes things harder to follow especially if people are inserting the code into their own subversion repositories.b) Hidden folders/directories might be distributing information that the distributor does not want and should be sharing (passwords, usernames etc.).Fix : Use svn export to export the release that is being prepared. Do not copy files in an ad-hoc manner from personal working folders. It will only cause confusion.5) Older snapshot is removed as soon as new snapshot is introduced.a) This might be o.k. if there was 1:1 mapping between release snapshots and code repository.Fix : While there is not a 1:1 mapping between release snap shots and code repository, release snapshots should be kept around. In fact the history of the releases is just as important (maybe even more) as the code history it self. That history should be kept around.Happy releasing!

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • Man the formatting was messed up. The folder layout should be:

    Change from 

     

    trunk/ProjectA

    trunk/ProjectB

    trunk/libraries_for_A_and_B

     

    to 

     

    trunk/ProjectA/Application

    trunk/ProjectA/libraries

    trunk/ProjectB/Application

    trunk/ProjectB/libraries

     

This reply was deleted.

Activity

DIY Robocars via Twitter
RT @TinkerGen_: "The Tinkergen MARK ($199) is my new favorite starter robocar. It’s got everything — computer vision, deep learning, sensor…
Monday
DIY Robocars via Twitter
Monday
DIY Robocars via Twitter
RT @roboton_io: Join our FREE Sumo Competition 🤖🏆 👉 https://roboton.io/ranking/vsc2020 #sumo #robot #edtech #competition #games4ed https://t.co/WOx…
Nov 16
DIY Drones via Twitter
First impressions of Tinkergen MARK robocar https://ift.tt/36IeZHc
Nov 16
DIY Robocars via Twitter
Our review of the @TinkerGen_ MARK robocar, which is the best on the market right now https://diyrobocars.com/2020/11/15/first-impressions-of-tinkergen-mark-robocar/ https://t.co/ENIlU5SfZ2
Nov 15
DIY Robocars via Twitter
RT @Ingmar_Stapel: I have now explained the OpenBot project in great detail on my blog with 12 articles step by step. I hope you enjoy read…
Nov 15
DIY Robocars via Twitter
RT @DAVGtech: This is a must attend. Click the link, follow link to read the story, sign up. #chaos2020 #digitalconnection #digitalworld ht…
Nov 15
DIY Robocars via Twitter
RT @a1k0n: Got a new chassis for outdoor races (hobbyking Quantum Vandal) but I totally didn't expect that it might cause problems for my g…
Nov 11
DIY Drones via Twitter
First impressions of the Intel OpenBot https://ift.tt/36qkVV4
Nov 10
DIY Robocars via Twitter
Nov 9
DIY Robocars via Twitter
Excellent use of cardboard instead of 3D printing! https://twitter.com/Ingmar_Stapel/status/1324960595318333441
Nov 7
DIY Robocars via Twitter
RT @chr1sa: We've got a record 50 teams competing in this month's @DIYRobocars @donkey_car virtual AI car race. Starting today at 10:00am…
Nov 7
DIY Robocars via Twitter
Nov 6
DIY Robocars via Twitter
RT @a1k0n: Car's view, using a fisheye camera. The ceiling light tracking algorithm gave me some ideas to improve ConeSLAM, and having grou…
Nov 5
DIY Robocars via Twitter
RT @a1k0n: To get ground truth I measured the rug, found the pixel coordinates of its corners, calibrated my phone camera with my standard…
Nov 5
DIY Robocars via Twitter
RT @a1k0n: @DIYRobocars is back in December, but outside. Time to reinvestigate ConeSLAM! I rigged up a quick and dirty ground-truth captur…
Nov 5
More…