FWIW, I have run against the same ~/.netbeans/dev since 2015. I think there have been a few releases in that time. That said, there are a lot of NetBeans modules I do not use.
The directory per release thing has always seemed a bit draconian. It might be preferable to do this instead: - On startup, the IDE looks for, say, $USERDIR/releases/$MY_RELEASE_VERSION - a 0 byte file - If it does not exist, it creates it - If it does exist, if listing $USERDIR/releases/$MY_RELEASE_VERSION does not show a file whose name sorts to > $MY_RELEASE_VERSION, continue startup - If the userdir *has* been used with a newer release of NetBeans, either abort startup with a message (not nice) offering to delete the userdir, or something more respecting of the common case (everything works) that says, say *A newer version of NetBeans has been used with your saved settings, and may have modified them incompatibly. If you continue, some functionality may be broken.* * [Continue Startup] [Delete Settings and Start] [Exit]* To my mind, anyway, the convenience for the user of keeping their settings outweighs the value of "developer has to fix a forward compatibility bug" - we develop software to make life easier for our users, not ourselves. If you wanted to solve the forward compatibility problem *fully*, the system filesystem could contain all older userdirs as read only layers up to its own version, and writes go to the current version, while historical settings are preserved and used but not written to - that would let someone downgrade safely, since the IDE simply wouldn't include userdir layers for versions newer than itself. But I suspect the performance effects of adding N disk filesystem layers to the system filesystem might be greater than the value. -Tim -- http://timboudreau.com
