Wednesday, February 15, 2017, 12:43:31 AM, David E Jones wrote: > 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.
According the above we would still allow that... you can call cfg.setXxx() anytime. But I have started a new thread about Configuration mutability. > 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. I think other projects get away without something like incompatibleImprovements be breaking backward compatibility more often. Note sure I want to push that on the users. So I would leave the infrastructure on the place, and if we don't use it (or not much), then hopefully it won't increate code complexity significantly. And ideally we won't need it, because we are careful and all, but that needs lots of eyes and mistakes do slip in. And on the day it will be needed, the architecture will be ready for it. > -David -- Thanks, Daniel Dekany
