incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <>
Subject Re: Tabularize the cloudmonkey response
Date Sun, 06 Jan 2013 23:37:49 GMT
On Sun, Jan 6, 2013 at 4:39 PM, Rohit Yadav <> wrote:
> On 06-Jan-2013, at 1:31 PM, Sebastien Goasguen <> wrote:
>> Can't we just consider cloudmonkey source as "stable" release within a cloudstack
release. and just consider the pypi as "unstable" dev..
>> after all anyone can grab cloudmonkey latest from master and push it to pypi ...
>> IMHO it's just an issue of understanding that pypi release is not an official ACS
release artifact.
> I think for now let's keep it that way, or we can have frequent release cycles of cloudmonkey
that are being voted by community and released on pypi?

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.)
Anecdotally I hear that Apache communities in the past who have had
3rd parties release 'development' snapshots and never release the
software themselves have had the board take issue with that behavior.
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.
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.
4. How (in your current scheme) would you delineate between snapshot
packaging (what you've done heretofore) and a real release?
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?

In short I see a huge number of potential problems that may manifest
as we move forward. 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. 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

Regarding #2 above, take a look at a number of examples of pre-release
and snapshot packaging here:

View raw message