On Tue, 2017-02-14 at 21:32 +0100, Daniel Dekany wrote: > I propose that in FM3 Configuration should only have two constructors: > > Configuration(Version incompatibleImprovements) > Configuration(Properties properties) > > and that it should not have a setIncompatibleImprovements(Version) > method. Because then it can be ensured that > cfg.incompatibleImprovements is always set first, and not modified > anymore. It's simplifies life considerably, because changing the > incompatibleImprovements changes the default of some settings, so when > in FM2 you change it at some later point, we will have to figure out > which settings were never set with the public setter method, and thus > still hold the initial default (not just something that's identical to > it!), and thus has to be changed. Because Properties are esentially > unordered, we also have to get all of them at once, so that we can > sort them (bring incompatibleImprovements to the first place, sort any > other dependent settings too).
Not allowing configuration changes after init is very reasonable. I don't know about others, but for my part I wouldn't miss the whole Version and incompatible improvements concept if it went away. Most libraries these days use semantic versioning (major.minor.patch) and release notes to communicate when changes are not backward compatible (usually a major version bump, with minor versions for backward compatible new features and patch versions for just bug fixes). Along with this there is typically a branch for each major or even minor version so that backported or direct fixes in previous releases can just go into that code base. Supporting just one version per code branch (the latest being in the trunk) would significantly simplify the code and avoid runtime overhead, even if it is just in template parsing (not sure this is an issue in any way now, just a potential one that crossed my mind). There is always the issue of maintenance of previous release branches, but this might actually be easier than basically supporting a spec for each Version in the same code base. It would definitely be easier for more contributors to get involved with the trunk for new features as well as with release branches for maintenance and bug fixes. -David
