cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <>
Subject CloudMonkey 5.0 (was Re: CloudMonkey's new home)
Date Fri, 09 Aug 2013 21:02:45 GMT
Hi folks,

Looks like the previous thread failed to capture attention on the dev ML.
I'm going forward with some decisions so as to move fast and as per our
philosophy to ask for forgiveness later than just waste time on too much
process polling now.

Here are some proposals;

- The version model would be to move fast, break things, release early and
release often
- Start with 5.0 version: Since cloudmonkey 4.x is already out there, I'm
proposing we start new cloudmonkey releases from 5.0; This is just to make
sure we don't end up releasing a 1.0 when we already have a 4.x
- Using semver, we don't deviate from major version "5" until we have
backward incompatible changes of configuration, paths, DSL etc.
- We'll use git tags to track (unvoted) releasable or testable candidates.
This is so we can release fast, release often. We can append a -rc for such
releases on git and pypi.
- A tested and voted release could take time and some process; but pypi
channel may not be necessarily used for only official releases, but all and
every release, even the test ones.

Suggestions, flames?

Moving forward, as it seems already, I may not be able to contribute on

I may be only able to help with the first release, that too the non-process
oriented parts, perhaps people who already have some idea about the
internals of cloudmonkey like Prasanna or Sebastien can help lead the


On Sun, Jul 28, 2013 at 11:04 PM, Rohit Yadav <> wrote:

> Based on our previous discussion thread[1], we've moved CloudMonkey out of
> ACS's repository to its new home [2]. Now,
> with 6f84e74a68d78705a06fe58f7927f42f61453a16 on master, we no longer have
> cloudmonkey in tools/cli. CloudMonkey will be within CloudStack project but
> now as an independent sub-project with its own repository and will have a
> faster need-basis release cycle.
> For doing that, please suggest on the release process or how it should
> work? If the present RM or someone wants to lead the release process?
> I just want to keep it simple with fast releases whenever we have a
> releasable candidate and semver[3] versioning. So, we ship things fast and
> don't worry if it breaks since we'll be shipping fast. We can after a fast
> lazy consensus/voting and publish via pypi and put the tarballs/zipballs
> under dists/ on ASF/CloudStack.
> Regards.
> [1]
> [2]
> [3]

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message