# Themes for 1.0, and future goals **URL:** \ **Category:** Ansible Project\ **Created:** [December 3, 2012, 2:40pm UTC](https://forum.ansible.com/t/themes-for-1-0-and-future-goals/12116 "2012-12-03T14:40:03Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [December 3, 2012, 2:40pm UTC](https://forum.ansible.com/t/themes-for-1-0-and-future-goals/12116/1 "2012-12-03T14:40:03Z")
Earlier I had stated that a 1.0 release doesn't mean a lot to me as a milestone number. Though, given that Ansible has evolved to the point where I want it to be, I think it's a bit of a coincidence that 1.0 is that number! Language and implementation wise, Ansible has reached the goal I set out for it. It is (generally) simple and accessible (though sometimes folks push it a bit further than I intended -- I encourage everyone to write as human readable playbooks as possible), but I don't want to keep expanding it in an unbounded way. What I want to do now is shift a bit in the way we are looking at releases, and Ansible in general. This is a really high energy community, and I want to shift it a bit, and I want us to slow down and spend some time looking at a mostly stable set of code. So, for 1.0, here is how I am going to be looking at pull requests -- (A) We are going to slow down adding new large features and make sure we really need to have something. If 2000 people didn't need X before, and we get a request for X, do we really really need X? Etc. (B) We are going to try to stop moving code around. In the interest of low bug counts, I want to see surgical pull requests, not large code changes or refactorings. We have had a lot of churn around template evaluation and variable precedence -- and lots of great fixes, but I don't want to experience that kind of defect volume again. So, code is largely going to become a boring endeavor of keeping it running. (C) We are going to try to bound the rate of growth of modules/plugins, and concentrate more on making sure modules are solid and cross platform, and fix problems where they are found. The criteria for addition of any new module is something that would be used by at least 10-15% of the user base -- such that any bugs or limitations on the module are found nearly \*instantly\*. In summation, the goal for 1.0 should be to have a very uninteresting changelog -- and take bugfixes for various modules and things when they come in. I want to prevent Ansible from growing unbounded on the core feature front, so it remains possible to fully understand in a relatively short period of time. So, if I seem like I'm closing too many pull requests, this is why... it is because I think we're basically there, and our goals should therefore change a bit. --Michael ---
**Author:** ![Matt\_Coddington](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Matt\_Coddington](https://forum.ansible.com/u/Matt_Coddington)\ **Post date:** [December 3, 2012, 4:35pm UTC](https://forum.ansible.com/t/themes-for-1-0-and-future-goals/12116/2 "2012-12-03T16:35:34Z")
Hi Michael, What are your thoughts on the future plans for the REST interface and potential web front end that came and went a couple times in the past few months? I’m definitely interested in something that would allow users to execute specific playbooks and get feedback from their execution via a web front end (test environment deployments are a great example), though I’m less interested in being able to manage inventory from such a front end, which was the initial thrust of ansible-commander a couple months ago. Hopefully I’m not the only one but I’d be curious about both your thoughts and whether anyone else is still interested in this 🙂 thanks! matt ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [December 3, 2012, 4:42pm UTC](https://forum.ansible.com/t/themes-for-1-0-and-future-goals/12116/3 "2012-12-03T16:42:25Z")
Right ... I think our thoughts around inventory was that it was more likely inventory would be managed by external scripts too, which is why the REST interface around inventory did not exist. We still should allow the inventory file location to be a directory such that it can contain multiple files and/or scripts, or otherwise support multiple inventory files with ":" as a seperator (either way). As for triggering playbooks via a REST interface, I'm not against it... though I don't think it's something core needs. It would be great to have an example somewhere on github to point to, and if using something like the keychain project to wrap SSH agent, it does not seem to be \*that\* complex, though it should probably talk to a job engine of some kind and include some callbacks. In any event, it's not something I personally am going to be working on, but it would be nice to have as a seperate project if someone wants to build it. --Michael