anchor.diff:  ** `add` command: add a version of a package
   ** `delete` command :  delete a version of a package
   
  +==== How to upgrade?
  +Use the add command to add a version that is bigger than the current version
  +
  +==== How to downgrade ?
  +Use the delete command to delete a version that is the highest and the next highest version will be chosen
  +
  +==== Using multiple versions in parallel in each collection
  +We use the `params.json` in the collection config to store a version of a package it uses.  by default it is the $LATEST.
  +[source, json]
  +----
  +{"params":{
  + "PKG_VERSIONS": {
  +   "mypkg": "0.1",
  +   "pkg2" : "$LATEST",
  + }}
  +----
  +* for `mypkg` use the version `0.1` irrespective of whether there is a newer version is available or not
  +* for `pkg2` use the latest. This is optional. The default is ‘$LATEST’
  +
  +==== The workflow
  +* A new version of a package is added
  +* The package loader loads the classes and notifies every plugin holder of the availability of the new version
  +* It checks if it is supposed to use a specific version, Ignore the update
  +* If not, reload the plugin
  +
  +
   ==== Using them in Plugins
  -Any class name can be prefixed with the packagename e.g : `mypkg:fully.qualified.ClassName` and Solr would use the latest version of the package to load the classes from.
  -
  -example:
  +Any class name can be prefixed with the packagename e.g : `mypkg:fully.qualified.ClassName` and Solr would use the latest version of the package to load the classes from. The plugins loaded from packages cannot depend on core level classes.
  +
  +*Plugin declaration in `solrconfig.xml`*
  +
  +[source, xml]
  +----
  +<requestHandler name="/myhandler" class="mypkg:full.path.to.MyClass">
  +</requestHandler>
  +----
  +
  +==== Full Working example
   
   1) create a package
   
  
positive.code: ----
  
  == Package Store
  Package store is a distributed file store which can store arbitrary files in the file system. It is a peer to peer hierarchical storage system. If a new node comes up and it requires any of these files it can be downloaded from one of the nodes where it is available.
  
  === Package Store APIs
  
  
negative.code: 
  A Package in Solr may contain one or more .jar files and any no:of plugins.
  
  == Objectives
  
  * Zero disruption deployment (hot deployment): Should be possible to install and update packages without node restarts or core reloads, and hence deployments should be quick and without failed requests or stale caches.
  * Easy packaging:
  ** Standard plugin concepts, e.g. query parser, search component, request handler, URP etc., should be supported without any special code/packaging changes.
  ** Artifacts (jars containing custom plugins) that users have already deployed (and are using in production) should be compatible, without needing to recompile or re-package, for greater adoption.
  ** Should support single jar packages as well as multiple jar packages.
  ** Use familiar / standard naming
  ** Use industry standard concepts and terminology around package manager, similar to those like apt, dnf, homebrew etc.
  
  
  == Classloaders
  
  At the heart of the system, we have classloader isolation. To achieve this, the system is simplified into two layered classloaders:
  The root classloader which has all the jars from Solr classpath. This requires Solr node restart to change anything.
  A set of named classloaders that inherit from the root classloader. The life cycles of the named classloaders are tied to the package configuration in ZK. As soon as the configuration is modified, the corresponding classloaders are reloaded and components are asked to reload.
  
  
  == A Plugin
  
  