On 06-Jan-2013, at 3:37 PM, David Nalley <da...@gnsa.us> wrote: > > So lots of places do 'unofficial' releases, but what is odd here is: > > 1. We (the ACS community) have no plans around releasing Cloudmonkey. > (unless the plan is to make it a part of the CloudStack release.)
Yes, it was planned to have a CLI for CloudStack: https://issues.apache.org/jira/browse/CLOUDSTACK-132 And, yes I want to make it a part of the CloudStack release. > 2. It has a version number - despite never being released, a version > number exists. Typically when an individual releases development > snapshots (as opposed to a community doing a release) it ends up being > the version number of the last release (or 0 if there has never been a > release - plus the release tag being incremented to annotate that it's > either a snapshot or a pre-release package. So, the version number refers to the fact against which CloudStack version/snapshot it was developed and yes it was released as a community release (i.e. the author or one of the members of the community released it, right now the admins for the pypi account are Chip and I). What we want is an official release. I was not clear how to proceed, so I've a proposal in a new thread coming up. > 3. What happens if the ACS community decides that it wants to release > CloudMonkey version 1.0.0 at some point in the future? IMO defining a > version number is equivalent to performing a release. I'll propose on how we should do releases for CloudStack on ML right away. > 4. How (in your current scheme) would you delineate between snapshot > packaging (what you've done heretofore) and a real release? Yes, this thing is not being followed now. But right now the pypi distribution page mentions that it's unofficial now and starting 4.1 we'll do releases after voting on it. > 5. Follow-on question to that. How do you file bugs against it? The > primary way folks get access to cloudmonkey is to install it from pypi > I'd suppose. There is no revision information in the releases - there > are 4 different releases (with the difference being the release tag, > but presumably those are different pieces of code. How does one even > know where in time their version is? The version/name syntax is cloudmonkey-<CloudStack version>-<cloudmonkey revisions on that major version>. > I am also interested in why you, the primary > author of CloudMonkey, who sees the need to release more frequently > hasn't proposed making a separate CloudMonkey release. Why not separate cloudmonkey: 1. https://issues.apache.org/jira/browse/CLOUDSTACK-132 2. Dependency on apidoc and marvin target, build dependency with API discovery plugin (coming up soon) there won't be any build dependency so if that works out we can separate out the src as a separate repo. > I don't think > there is anything inherently that prohibits you from doing so, aside > from having to handle release management. Yes, a separate repo might > be cleaner, but I don't know that it means you can't generate a > release. Proposal coming up, looking fwd to your views on it! Regards. > > Regarding #2 above, take a look at a number of examples of pre-release > and snapshot packaging here: > [1] http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages > [2] > http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages
