cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <bhais...@apache.org>
Subject Re: CloudMonkey 5.0 (was Re: CloudMonkey's new home)
Date Sat, 10 Aug 2013 18:54:28 GMT
On Sat, Aug 10, 2013 at 10:32 PM, Daan Hoogland <daan.hoogland@gmail.com>wrote:

> +1 +question
>
> Is cloudmonkey 5 backwards compatible in the sense that it can talk to a
> 4.x ms?
>

Sorry for the confusion. Yes, in fact it is. It's the same cloudmonkey and
is aimed to work with Apache CloudStack 4.0.0-incubating and its
derivatives. If it does not it's a bug.

We're gaming the version number, since cloudmonkey-4.x was already out
here, it would create confusion if we release cloudmonkey-1.x. Therefore,
it made sense to just start with 5.0.0 and use semver from this version.

Regards.


>
> On Sat, Aug 10, 2013 at 5:50 AM, David Nalley <david@gnsa.us> wrote:
> > +1 move forward.
> >
> > On Fri, Aug 9, 2013 at 5:02 PM, Rohit Yadav <rohityadav89@gmail.com>
> wrote:
> >> 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 <bhaisaab@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/
> >>>
>

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