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 <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/ > >> >>> > >> >
