Meteor has always been tightly-bound to its environment. We need to provide separate tags for the major Meteor release versions. There have generally been major, sweeping changes between what would generally be considered minor version changes (e.g. 1.4 -> 1.5, 1.5 -> 1.6). We want to stay flexible, but we also want to stay current without breaking existing builds.
This means that:
we need static image tags from commit hashes
we need compatibility tags for Meteor releases (e.g. ulexus/meteor:1.6)
we need to figure out whether we should consolidate the build branch or continue to maintain that separately just for the sake of image size... especially considering Docker's new multi-staged build options
Meteor has always been tightly-bound to its environment. We need to provide separate tags for the major Meteor release versions. There have generally been major, sweeping changes between what would generally be considered minor version changes (e.g. 1.4 -> 1.5, 1.5 -> 1.6). We want to stay flexible, but we also want to stay current without breaking existing builds.
This means that:
ulexus/meteor:1.6)buildbranch or continue to maintain that separately just for the sake of image size... especially considering Docker's new multi-staged build options