> > Snap update mechanics would copy the user and cache dir over from the > > previous version to the new version. > > > > Does anyone know any reason against that? > > I do in-place upgrades with at least Windows installer in my own > NetBeans-based IDE project. Be careful with / possibly exclude cache dir > depending how you do it. Caused quite serious problems.
I suggest to avoid copying the cache as well. NetBeans Runtime Container caches are going to be invalidated anyway if the JAR bits change. > So, there's some caching issues with updated (and possibly moved files) not > being picked up. Don't forget to touch `.lastModified` files in each changed cluster. > > Also would it make sense do something similar with the non-snap packages? > Could you elaborate? Installer or UC based, or something else? Let's stop producing release ZIP files! Let's produce just NBMs and let them be updated one by one. This was always my dream ;-) Let's have following update centers: - "LTS NetBeans 13" - this would work like the 12.0uX - "Stable NetBeans 13" - this would replace the 12.x releases - "Alpha NetBeans 13" - daily produced bits for verifying fixes This approach failed in the past. However the situation may be better these days. We require 100% binary compatibility of exposed packages - that'd eliminate the biggest source of errors. -jt --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
