On 05/27/2014 11:44 AM, Bohuslav Kabrda wrote:
Big kudos go to all people who sent patches, tested, created bug
reports and shared their ideas with us. Thanks!
Thanks indeed!
- Development goes on in master branch. Master branch can be broken
from time to time (in the sense that we do new features that bring unexpected
regressions), but all the Travis tests have to keep passing.
I'll play the devil's advocate a bit. There's also an option of having a
branch for every separate feature and merging it into master after the
feature is stable and tested. Of course, when developing two or more
features at the same time in different branches, major issues may arise
when merging, but testing against the arguably more stable codebase is
much easier as opposed to an ever-moving master branch.
^ Just to spur the discussion :)
- Initially, I'd say we should support a minor release for at
least half a year, releasing micro releases as needed (no predefined schedule).
Second that. As DA is e. g. packaged in Fedora, having 0.8.0 there all
the time up till now is a real pain, as some major usability
improvements were made in the development of 0.9.0, and especially
towards the end of the cycle, the amount of polish made a huge difference.
Also, I'd like to add a rule "every new feature must have
unit tests testing its basic functionality".
Absolutely. In addition, I suggest that there be a client-side commit
hook that would run tests prior to every push, and disallow pushing if
they fail. Of course, this hook would be override-able to accommodate
for corner cases, but I think that it should prove beneficial in 99% of
the cases, as I got to review quite a few pull requests that broke tests
(and, admittedly, have made at least one myself).
Cheers, Tomas Radej