On Thursday, 3 January 2013 at 22:11:59 UTC, H. S. Teoh wrote:
We could either:
(1) Have an actual branch called 'staging', where changes made
to master
since the last merge are merged in immediately after release,
and when
things have sufficiently stabilized, we tag/branch that
particular
commit as release 2.X.Y;
(2) Or, we can follow Walter's suggestion of branching master
into 2.X.Y
after a release and just tag it as a release when it's
sufficiently
stable. In this case, the latest 2.X.Y branch acts as 'staging'.
Part of the draw of (1) is that betatesters and adventurous
people have
a fixed place to go to, to get the latest and greatest
features, but
without the instability of master.
(1) is what I was advocating precisely so that beta testers could
use it shortly after a release and up to the final next release.
There are a few benefits to this that may be under appreciated.
There's plenty of benefits to having a lot of beta testers, so we
want to draw them in and encourage them to use the latest beta
version as soon as possible. Real world programmers do not want
to make use of something that is too unstable, so they will tend
to avoid the master development branch and will prefer the latest
stable release instead. The only reason they will try out the
latest beta version, is to gain access to a bug fix or new
feature that they really need for their real world programming
tasks, but they will only try it out if they think that the beta
is stable enough and is not going to get horribly broken by
anything radical being merged in without proper oversight and
planning (that's what master and the related feature branches are
for).
If we immediately move master into the next staging after a new
release, and freeze the introduction of new features, only to
concentrate on stabilizing it for the next release, then we're
more likely to attract beta testers from the real world, these
are the guys who will do testing under the most realistically
conditions possible, something that in invaluable in gaining feed
back and routing our difficult to discover bugs.
I think (2) is more commonly what is actually done by software
companies
and projects. In this case, 'staging' isn't so much as an actual
physical branch, as the general concept of having a branch
(2.X.Y, which
changes per release) to stabilize things for a release, while
development on master continues unhindered.
The Linux kernel also uses a similar kind of process: X.Y.Z is a
development release (can be thought of as 'master') when Y is
odd, and a
stable release (can be thought of as 'staging' or Walter's
release
branches) when Y is even.
Basically, the idea is that master should be able to receive
the latest
and greatest features, completely unhindered, while stabilizing
the code
for a release is done in a separate branch which doesn't
receive new
features, but only bugfixes, prior to an actual release.
I'm not certain what the major difference is between (1) and (2),
because they both sound very nearly identical. In both cases,
they seem to provide the same goals of stabilizing the next
release, while allowing development to proceed unhindered, so if
(2) can be made to achieve the goal I described for attracting
real world beta testers, it may not matter which is used, however
I would suggest that we always focus on serving the needs of the
end user as a top priority as much as is possible. D requires
plenty of significant end users working on significant projects.
You did mention that (1) is more suitable for beta testers, so I
ask how is (2) not as suitable?
--rt
