pcb-rnd knowledge pool
pcb-rnd release policy: trunk, tags, tarballs
trunk_release by Tibor 'Igor2' Palinkas on 2016-12-05 | Tags: insight, release, releasing, timeline, tags, source, tarball |
Abstract: Release policy of pcb-rnd and how to keep dual (or multiple) installations for testing.
Imported from the mailing list archives.
pcb-rnd release policy
- we try to make releases rock solid, so if you use an official release, that should have no major bug or regression compared to the last one
- relases are collected in svn in the /tags directory (as recommended by the svn book); you could do an "svn ls svn://repo.hu/pcb-rnd/tags" to see what versions we have and check out one. The last few release tarballs are also available on the web.
- svn /trunk is always the latest "development snapshot", might be unstable or buggy and may have temporary regressions; although I try to carry out even largish refactorings in a series of working intermediate commits, the code base is so huge that I sometime miss newly introduced bugs (like this gerber layer name thing). I am working on improving the automated test system to make it easier to catch these (user help needed on this!)
- I try to maintain predefined, public release timeline so users can follow the process and know what to expect from trunk/; I try to do restrict myself to do the refactoring/cleaning in the first 1/3 of a development cycle and keep the last 1/3 for minor bugfixes so we have time to test out the changes before we release. You can find the timeline at http://repo.hu/projects/pcb-rnd under the timeline menu.
dual-version installs
A good strategy for dual-version is to install the last release (either from svn tags or from a tarball release) and keep trunk/ uninstalled. You can always run trunk from source:
cd trunk/src ./pcb-rnd
to test the latest/greatest feature while if you start pcb-rnd from anywhere else you get the latest stable. It's also a good idea to configure the trunk/ version with --debug while keep the stable version in production settings, for speed - debug slows polygons a lot.