On Mon, Aug 26, 2013 at 10:53 PM, Chip Childers <[email protected]> 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 <[email protected]> wrote: >> > On Sat, Aug 10, 2013 at 10:32 PM, Daan Hoogland >> > <[email protected]>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 <[email protected]> wrote: >> >> > +1 move forward. >> >> > >> >> > On Fri, Aug 9, 2013 at 5:02 PM, Rohit Yadav <[email protected]> >> >> 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 <[email protected]> >> >> 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/ >> >> >>> >> >> >>
