On Mon, Aug 26, 2013 at 10:53 PM, Chip Childers
<chip.child...@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 <bhais...@apache.org> wrote:
>> > On Sat, Aug 10, 2013 at 10:32 PM, Daan Hoogland 
>> > <daan.hoogl...@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 <rohityada...@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 <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/
>> >> >>>
>> >>
>>

Reply via email to