Mats Lidell writes:
The idea with using feature-flags is that they by default are
turned off so a beta tester, and even in released code, you won't
notice unless you turn that flag on.
That's the theory. Amusingly enough, in this very thread we're
observing that Jerry's changes have broken things even though they're
turned off. That happens to ordinary mortals and Ben Wing alike.
It is not practical to use for all things but is a technique to
avoid branching.
Branching was nearly impossible in RCS, not terribly useful in CVS,
only a little bit better in Subversion. But things have changed (Bzr
is dead, long live King Git!) There is no good reason to avoid all
branching any more, and skilled branchers can use branching for all
kinds of tasks that in the past we would use ifdefs or quilts or
whatever for. That's because when using git, the costs of merging to
the developer are much less, and the benefits to users much greater.
As long as the developer frequently merges from trunk to feature
branch, this strategy works very well. The only real cost is that
while on the branch the beta testers and others find it hard to
discover the feature branch. (I'm serious, that is a cost I worry
about.)
Just right now it can of course be problematic since we don't
have
any support for feature flags but could be a fun thing to
implement. ;-)
I don't understand. Do you mean like in Gentoo, USE flags and FEATURE
flags are recognized by emerge? But that's strictly a Gentoo thing,
isn't it? And most of the people I know, including some ex-Gentoo
maintainers, are moving away from Gentoo -- it's a niche platform.
For use with XEmacs itself, we have Customize and "behaviors" at
runtime, and configure options (easily captured in a shell script or
the .INC file on Windows) for build time. What more do we need?
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-patches