You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Rohit Yadav <ro...@gmail.com> on 2013/08/09 23:02:45 UTC
CloudMonkey 5.0 (was Re: CloudMonkey's new home)
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 <bh...@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/
>
Re: CloudMonkey 5.0 (was Re: CloudMonkey's new home)
Posted by Rohit Yadav <bh...@apache.org>.
On Mon, Aug 26, 2013 at 10:53 PM, Chip Childers
<ch...@sungard.com> wrote:
> On Sun, Aug 11, 2013 at 01:06:37PM +0200, Daan Hoogland wrote:
>> ok, the down side will be that the semantics of the versioning are
>> confusing when cloudstack 5 comes and the version numbers don't match.
>> still a +1 from me though.
>
> I find it confusing as well, but am OK with a stable 5.x line being the
> start of the new repo's release versioning. Since I know that Rohit is
> focused on other things now, I'm going to pick this up and figure out
> what is needed to get the first independent CloudMonkey release out the
> door.
Thanks Chip for taking the further.
Regards.
>
>>
>> On Sat, Aug 10, 2013 at 8:54 PM, Rohit Yadav <bh...@apache.org> wrote:
>> > On Sat, Aug 10, 2013 at 10:32 PM, Daan Hoogland <da...@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 <da...@gnsa.us> wrote:
>> >> > +1 move forward.
>> >> >
>> >> > On Fri, Aug 9, 2013 at 5:02 PM, Rohit Yadav <ro...@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 <bh...@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/
>> >> >>>
>> >>
>>
Re: CloudMonkey 5.0 (was Re: CloudMonkey's new home)
Posted by Chip Childers <ch...@sungard.com>.
On Sun, Aug 11, 2013 at 01:06:37PM +0200, Daan Hoogland wrote:
> ok, the down side will be that the semantics of the versioning are
> confusing when cloudstack 5 comes and the version numbers don't match.
> still a +1 from me though.
I find it confusing as well, but am OK with a stable 5.x line being the
start of the new repo's release versioning. Since I know that Rohit is
focused on other things now, I'm going to pick this up and figure out
what is needed to get the first independent CloudMonkey release out the
door.
>
> On Sat, Aug 10, 2013 at 8:54 PM, Rohit Yadav <bh...@apache.org> wrote:
> > On Sat, Aug 10, 2013 at 10:32 PM, Daan Hoogland <da...@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 <da...@gnsa.us> wrote:
> >> > +1 move forward.
> >> >
> >> > On Fri, Aug 9, 2013 at 5:02 PM, Rohit Yadav <ro...@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 <bh...@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/
> >> >>>
> >>
>
Re: CloudMonkey 5.0 (was Re: CloudMonkey's new home)
Posted by Daan Hoogland <da...@gmail.com>.
ok, the down side will be that the semantics of the versioning are
confusing when cloudstack 5 comes and the version numbers don't match.
still a +1 from me though.
On Sat, Aug 10, 2013 at 8:54 PM, Rohit Yadav <bh...@apache.org> wrote:
> On Sat, Aug 10, 2013 at 10:32 PM, Daan Hoogland <da...@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 <da...@gnsa.us> wrote:
>> > +1 move forward.
>> >
>> > On Fri, Aug 9, 2013 at 5:02 PM, Rohit Yadav <ro...@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 <bh...@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/
>> >>>
>>
Re: CloudMonkey 5.0 (was Re: CloudMonkey's new home)
Posted by Rohit Yadav <bh...@apache.org>.
On Sat, Aug 10, 2013 at 10:32 PM, Daan Hoogland <da...@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 <da...@gnsa.us> wrote:
> > +1 move forward.
> >
> > On Fri, Aug 9, 2013 at 5:02 PM, Rohit Yadav <ro...@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 <bh...@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/
> >>>
>
Re: CloudMonkey 5.0 (was Re: CloudMonkey's new home)
Posted by Daan Hoogland <da...@gmail.com>.
+1 +question
Is cloudmonkey 5 backwards compatible in the sense that it can talk to a 4.x ms?
On Sat, Aug 10, 2013 at 5:50 AM, David Nalley <da...@gnsa.us> wrote:
> +1 move forward.
>
> On Fri, Aug 9, 2013 at 5:02 PM, Rohit Yadav <ro...@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 <bh...@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/
>>>
Re: CloudMonkey 5.0 (was Re: CloudMonkey's new home)
Posted by David Nalley <da...@gnsa.us>.
+1 move forward.
On Fri, Aug 9, 2013 at 5:02 PM, Rohit Yadav <ro...@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 <bh...@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/
>>