This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 55647 - [65cat] Allow user to choose which version to import settings from
Summary: [65cat] Allow user to choose which version to import settings from
Status: RESOLVED FIXED
Alias: None
Product: ide
Classification: Unclassified
Component: Import Settings (show other bugs)
Version: 5.x
Hardware: PC All
: P3 blocker with 1 vote (vote)
Assignee: Jiri Skrivanek
URL:
Keywords:
Depends on: 42157
Blocks: 60750
  Show dependency tree
 
Reported: 2005-03-01 02:30 UTC by misterm
Modified: 2009-04-16 15:02 UTC (History)
5 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description misterm 2005-03-01 02:30:17 UTC
[ JDK VERSION : J2SE 1.4.2_xx ]

If a user instal
led nb4 once, didn't keep it and kept using 
3.6, it's not possible to import settings from 
the 3.6 release without manually deleting the 
4.0 dir. The "first use" process should display a
 dialog that allowed the user to choose which IDE
 version to import settings from in this case, def
aulting to 4.0
Comment 1 Jan Chalupa 2005-05-05 11:30:27 UTC
Definitely won't be implemented in 4.1. Need to decide whether this should be
implemented in future releases. Going forward we may want to support migration
from the last release only.
Comment 2 misterm 2005-09-29 20:51:41 UTC
I have submitted this during 41cat, but it's relevant for this release as well.
Comment 3 ulfzibis 2007-10-31 20:41:05 UTC
Was submitted during 41cat, but it's relevant for current release as well.
Comment 4 pdxlooie 2007-12-09 19:48:30 UTC
The case is that I have a current release.  I install a beta, import settings from current and then make further changes
(e.g., to take advantage of new features).  Now I install the new final release and I have only the option to again
import settings from the previously current release and then redo all the settings I changed in the beta.  I completely
miss the logic of this process.  In fact, it seems to actively discourage use of new beta settings.
Comment 5 Peter Nabbefeld 2008-01-24 05:44:53 UTC
I've seen, that settings api is in a state of being changed, so hopefully it will become easier to migrate settings in
the future. However, it should be possible to migrate from 5.0, at least.

IMO, one problem with migration is, that You want to migrate everything at once, while I'd prefer every module having
its own migration layer (which should *not* be integrated in the standard layer file, as bugs may compromise the whole IDE).

Every module should tell, how to migrate its settings from one implementation version to the next, possibly using its
own migration implementation.

To make it clear:
- Projects should not be thought of as private module settings, so there should be a separate panel.
- Modules should be possible to be used, probably updated, in a newer IDE version (if available)
Comment 6 Peter Nabbefeld 2008-01-24 17:44:12 UTC
Just some more comments, what IMHO settings migration should look like:
- each module should have its own migration layer, which should have entries about which versions it can migrate,
  e.g. from 3.4 to 4.0, from 4.x to 5.0, from 5.x to 6.0 etc. In this example it would declare for every migration
  step, how to migrate from one version to some other. This incremental procedure has the advantage, that also
  rather old settings can be migrated, if the user didn't upgrade some time because of special needs
  (e.g. needing some module, currently not supported, but probably later re-implemented)
- migration steps could be declarative (e.g. just copying some folders and setting default values for new opts)
  and/or procedural (e.g. an option might be split for user convenience, so this could probably only be done
  using a utility method).
- if a module changes the code base name for some reason or is even split, this should also be mentioned in the
   migration layer and later be added to the update center's information, so the migration can transparently select
   the correct module(s) to upgrade. This makes also sense for external writers, who are contributing their
   modules later.
- this all could, probably, look like this:
   <migrationLayer>
      <!-- The new codebase is known ny manifest -->
      <codebase old="org.contrib.anything"/>
      <!-- probably an api-module which has been seeparated into its own module -->
      <add file="a-dependeny.nbm"/>
      <migrate from="3.4" to="$">
          <!-- migration from 3.4 to current version -->
          <move from="config/mymod" to="config/mymod/myvalues">
          <folder name="config/mymod/extensions">
             <attr name="newvalue" stringvalue="smile"/>
          </folder>
          <call name="org.netbeans.modules.mymodule.MigrationUtil.migrate"/>
      </migrate>
   </migrationLayer>

- While projects are known to the IDE, there should of course also a possibility for migration over several versions.
   However, as every project type needs to handle this by its own, I'll not provide some proposal here.
- With upgrading modules: see the above

And, please, remember: this is only a proposal, as nothing has happened to this issue for a very long time - feel free
to find a better solution ;-)
Comment 7 Peter Nabbefeld 2008-01-25 05:24:49 UTC
Ooops - the "<add file ..." is redundant, as the dependency is already declared in the manifest ... :-)
Comment 8 Antonin Nebuzelsky 2008-04-15 17:09:38 UTC
Reassigning to new module owner jskrivanek.
Comment 9 Michel Graciano 2008-07-16 01:34:23 UTC
Any chance for see this soon?
Comment 10 Quality Engineering 2008-12-23 14:22:25 UTC
This issue had *5 votes* before move to platform component
Comment 11 Jiri Skrivanek 2009-04-16 15:02:59 UTC
Now it is possible to import settings from arbitrary userdir. Open Tools>Options, click Import, browse for your userdir
and finish the import.