RE: defcustom :version

[Drew Adams]

    > Here's an idea.  customize-changed could work like customize-browse,
    > except that it would show only the groups that cover settings which
    > have changed meanings.  What do you think?

    I like it, with one caveat.
    As I browsed the output of customized-changed, a couple of variables
    caught my eye that I would have missed if they were hidden in a tree
    structure. However, that concern would be mitigated with an Expand All
    button (with a corresponding Collapse All button).

I have not been following this thread closely. However, if the question is
about changing the behavior of `customize-changed' now (before the release),
then I am against it.

I don't want to hear (or to miss) "Here's an idea" proposals about the
Customize design now, unless it's to discuss changes that might occur
_after_ the release.

In particular, if the idea is to have `customize-changed' not show every
single change, or to enclose the changes within a tree structure of groups,
then I am against it at the present time. If some such abbreviation is
(also) useful sometimes, then we can create a new command to do that. But
why do even that before the release?

We need a real discussion or two or three about Customize after the release.
Please, let's not make changes to the Customize design now.

Apologies if I misunderstood the question. I have not followed this thread.
If this is about fixing a bug, then please try to find a way to do that
without changing the design.