On 07/09/2013 06:45 PM, James Bromberger wrote:
On 10/07/2013 6:25 AM, Charles Plessy wrote:this opens the question of our naming scheme: 7.1 is the version of a Debian release, whereas 7.1a is not. Do you think that it is enough to assume that Debian will never use such version numbers, or shall we use a version scheme that makes it more explicit that it is the combination of a release number and a build number ?Great question. In the heat of issuing 7.1a, I needed something that was distinctly different. Squeeze went with three digits, Wheezy seems to be going with two. I think an Alphabetic character is significantly different and possibly unlikely to be used... but perhaps we want to separate in future with a period/dot between major debian release, and AMI/cloud re-releases? However for an initial release, I think it it really like the Cloud image version numbers being identical to the Debian release number - so we only introduce an additional letter/number when we have to do a re-release.
Jumping in the middle of a thread without context, but if you're talking about naming AMIs on EC2, there is a strong standard to include the YYYYMMDD build date somewhere in the AMI name.
This is important because EC2 does not provide any metadata about when an AMI was created. Without this date in the name, there is no easy way to know which AMI is the latest for a specific series and how current the software is on the snapshot.
On another topic, I understand the desire to remove AMIs for versions of an OS that are old, but I'd encourage you to think about the effects this might have in an EC2 environment.
In a standard hardware environment, a user might download a release and run it on their servers for years, even past when they should. You would encourage people to upgrade, but you would not put a switch into the distro that causes the machine to not boot once it has reached a specific point in time.
On EC2, there are many reasons people take a running instance and replace it with a new one. Other folks might have set up Auto Scaling so that new instances are started automatically as their traffic grows and terminated as their traffic dips.
If you delete an AMI that they are using, suddenly their entire site could stop working because Auto Scaling can no longer start new instances of that AMI, and folks are unable to replace instances that fail.
By deleting a public AMI, you are explicitly breaking any company that has not upgraded their EC2 infrastructure to use your newer AMIs.
This is a pretty strong statement. In the non-EC2 world, it is like reaching into every company's physical data center and changing their existing hardware server installations so that the servers will no longer reboot if they are running an old version of the operating system.
-- Eric Hammond