A few people, well ok, Lukas mainly, seem to be confused about our
current process, or lack of it. I think it is pretty simple, and it is
what we used for years. We commit all new code to trunk. Bug fixes
should obviously be committed to any active branches they apply to as
well. When we have enough new interesting code in trunk we branch and
release from that.
Sometimes there may be code in trunk that isn't quite ready. We then
either fix it, or the RM can decide to still branch and then revert
particular features from the new release branch.
The idea here is to get things active in our development branch again.
Feel free to commit minor things with little or no discussion. Make
sure you include a test case and that your change doesn't break the
build nor existing tests. You can always run a partial "make test" like
this:
make test TESTS=ext/soap
to only run the SOAP tests, for example.
Major changes/features should be discussed and probably RFC'ed, and if
there is general agreement, or even indifference, commit away. If there
are intelligent detractors, then try to work it out on the list.
So, don't wait around for talk of the next release. Get your code into
trunk as soon as possible so we have some time to work out issues. You
committing your code to trunk should be what speeds up the next release,
not the other way around.
-Rasmus
hi Rasmus,
A few people, well ok, Lukas mainly, seem to be confused about our
current process, or lack of it. I think it is pretty simple, and it is
what we used for years.
I'm pretty sure there are more people willing to change, to keep trunk
as the actual development tree and use well chosen patches for a given
release, branching from the current stable branch.
It requires a little bit more work but the benefits for us are
enormous, a viable and timely controllable release process.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org