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 weekends. 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 component? Regards. On Sun, Jul 28, 2013 at 11:04 PM, Rohit Yadav <bhais...@apache.org> 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] http://markmail.org/message/tjlr753xfhpw4uk4 > [2] https://git-wip-us.apache.org/repos/asf?p=cloudstack-cloudmonkey.git > [3] http://semver.org/ >
