<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">At the moment there are different snaps for each major version available (snap find postgres shows this), all of these in the stable channel. We are, however, working towards having smarter channels. Right now there is edge, which you can update with every commit to trunk. There's also beta, candidate, and of course stable.</div><div class="gmail_msg">We're aiming at having 9.6/stable, 9.6/candidate, 9.6/beta, 9.6/edge, 9.5/stable, 9.5/candidate, and so on, and also a "magic" latest family: latest/edge, latest/beta, etc. latest'stable would be the version you get when you ask the system to install any snap, without manually specifying the major version and flavour.</div></div></div></div></blockquote><div><br>This describes install, but not upgrade process.</div><div><br></div><div>If you upgrade by just replacing binaries, you should keep in mind postgres 9.6 can't work with database created in postgres 9.4 - so, you need pg_upgrade (+ several manual steps) to perform the upgrade.</div><div><br></div><div>If you install postgis, you have a postgis binary for each version of postgis for each version of postgres. After you connect to postgres database, you can switch the version of extension used, and several running simultaneous queries can be using different versions of postgis.<br><br>Packaging postgis+postgres in single package has a disadvantage - you can't use more than two extensions at the same time in that scheme.<br><br>How is it going to be handled?</div></div></div>