Hi,
Can you please create the following tracks for the posgresql snap (@iliv) so we can fold the existing snaps into a single snap with tracks:
11.0, 10.5, 9.6.10, 9.5.14, 9.4.19, 9.3.24
The rationale for including patch versions is that postgresql often changes between patch versions in a way that does not upgrade successfully without end user assistance. See for example the migration notes for each patch version:
Discussed face to face, and agree with the rationale, database consumers are very cautious with migrating between versions and will want the ability to lock down to a given upstream patch version.
+1
As @sparkiegeek says this has been discussed with Command Prompt in person at the Snapcraft Summit. Using tracks for Postgres is sensible. 
Tracks created as requested 
I understand there have been in person discussions, I don’t think the topic captures them appropriately though. I don’t understand whether tracks will be created for some patch versions or basically going forward we will get a track per each patch release?
They’ll be created for the patch versions. As mentioned in the opening, unlike other applications there are incompatibilities between patch versions of PostgreSQL that are not addressable without sysadmin involvement. If you review the migration instructions between patch versions in the release notes you’ll see examples of this.
Hi,
We’ve talked through this further with the upstream and the Store team. The Store team is understandably concerned that having patch version tracks (e.g. 9.4.19) for PostgreSQL, which changes between patch versions in a way that requires sysadmin handholding, will set a precedent that tracks could be used for every version of any application. As well, any update to a track would cause the services installed by that snap to restart immediately.
We’ve agreed with @iliv to move back to major.minor tracks for now, and work with the Store team next week to develop a longer term plan such that this snap could be used in production environments. Meanwhile, we’ll also change the description to warn that updates to a track will cause services to restart and thus this snap should only be used in dev and test environments.
So, let’s move to 11.0, 10.5, 9.6, 9.5, 9.4, and 9.3 for the track names. We’ll use snapcraft release to move the revision for 9.4.19 into 9.4 and so on.
When should we expect updated tracks?
Releasing package to channels failed: Track does not exist: 9.3
I have everything ready to publish today’s new PostgreSQL releases. Would be nice to push them all out on the same day.
We anticipate having the new tracks in place, and deleting the previous ones tomorrow. There’s a delicate admin operation needed to delete the tracks, and we want to make sure we get it right.
The new set of tracks seems to fit the usual patterns, assuming we manage to remove the finer grained ones. Again to facilitate going in-person through flows the wait period could be waived for the new set.
Again to facilitate going in-person through flows the wait period could be waived for the new set.
So, I just checked and the new set of tracks doesn’t seem to exist.
Sorry for the delay, we haven’t yet deleted the old tracks, but I have created the new ones to unblock further progress.
11, 10, 9.6, 9.5, 9.4, 9.3 are all in place.
