Add configuration versioning information

I'm confused as to what this can be used for?
Is it similar to the existing "update sequence" number?

The intention here is to track when internally we make code changes that affect configuration format, whereas updateSequence is used to track changes that users make to configuration.

The classic example is a major version upgrade like we did for 1.7.x to 2.0.x. In that case we use the existence of the files catalog.xml/services.xml as the marker. But perhaps for 2.0.x to 3.0.x the marker wont be so obvious so a number to track I think is a good idea.

A few comments regarding the patch:

1. It's not obvious what the difference between "implementation" and "specification" version mean... I guess the latter is the current version of geoserver configuration, and the former is the current version of the data directory?
2. This scheme will require developers to remember to update that number when we make configuration changes.. so we need a policy for that. Defining what changes require an upgrade (for instance, maybe simple additions don't?)
3. Ideally the "specification" version would just be the version of geoserver... 2.1.2, 2.1.3, etc...
4. This change probably actually requires a GSIP... even though the patch itself is fairly core so I think getting more feedback among the core devs will be good

Ok, so once we have a marker stating that the configuration somehow changed... how are we going to use it? Are extensions going to start to check that for some reason?
Is it restconfig? I'm still lost on where the usefulness of this is.

Well in this case I think the use case is for the user password encryption stuff... to know if the user.properties should be updated or not. But I will let Ian comment on that.

But in general I can think of cases where it would be useful. Think about (and this is hypothetical) if we ever moved to a resource publishing split. In the branch I experimented on it was actually tricky to detect if the data directory had already been updated or not... having configuration version would have been useful.

Justin covered the basic ideas.
As for Justin's comments:

1. specification would be tied to release functional specifications and implementation to the backend (if there ever is more than one)
2. Indeed - if the changes can be applied automagically with reasonable defaults and no breakage they qualify as simple additions though it might be useful to track them anyway (just to know what is new).
3. I thought about that, but they're actually separate and release versions would trigger changes even if there were none. Tying the release to a version makes more sense, e.g. 2.1.x now uses version 5.
4. Sounds fair.

And Andrea's:
The reason I considered this was the plain text password upgrade. For a small setup (1 user, a dozen StoreInfo objects), constantly checking for upgrades is no big deal. For a larger setup, this incurs needless pain. Part of this is due to what the password upgrade has to do (scan each DataStore and discover 'password' fields), but I looking forward, other cases are on the horizon:

1. alternate config backend (implementation version) changes
2. config cloning
3. future, unseen needs similar to password upgrade (the cumulative effect of all changes blindly scanning for markers would become a burden)

As for extensions, if there is config they might be concerned about (either direct or indirect), then yes. This of course implies some type of pub-sub mechanism that is not included here.

Cool, thanks for explaining