Github user bbende commented on the issue:
https://github.com/apache/nifi/pull/2219
@pvillard31 the current thinking behind variables is that they serve as a
starting point when someone imports a flow, but aren't considered as changes
that make a flow "dirty" and require a commit.
When a version of a PG is saved to the registry it does capture all of the
variables and their values at that point in time. So in a PG that already has
v1 saved to the registry, if you add a variable and make any other change, even
a positional change, then it will capture the new variable in v2.
Changes to variable values do not make a PG dirty because when a versioned
flow is imported to another NiFi instance, the user will most likely need to
change the variable values to something specific to the environment, along with
setting/changing sensitive properties and RPG URLs, which are both not part of
variables (eventually there could be a nicer way of identifying these things
that the user would want to modify after import). We don't want these changes
to make this newly imported PG appear as dirty, because then it couldn't be
upgraded to the next version without first saving or reverting these changes.
When a PG is upgraded, if it contains new variables that are not already
defined/visible in the PG being upgraded, then those variables will be added,
but it won't touch any existing variable values, and won't touch sensitive
properties or RPG URLs. This lets the user customize the values once on the
initial import, and then not have to redo it on every upgrade, they would only
need to customize newly added variables/sensitive props/RPGs.
There are definitely a lot of edge cases and different perspectives to
consider, and I think we can figure out what improvements need to be made based
on feedback as users start integrating the registry into their environments.
All that being said, the code that does the comparison of versions and
triggers a PG to be dirty is actually part of the registry
(nifi-registry-flow-diff). So any improvements/changes to that would have to be
made outside of this PR against the registry for the next release, either 0.1.1
or 0.2.0, whichever is decided.
---
