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!
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