- Here's the v5.5.0-2014.1.1 release notes
- Here's the v5.5.0-2014.1 release notes
If you're still using the December release, here's a unified change list between 5.5.0 and 5.5.0_2014.1.1:
- fixed session timeouts issue
- added RST documentation
- Fixes bug with Iso8601 date serialization (for messages sent to the service)
- Simplifies test-requirements.txt
- Introduces support for
tox
- Changes version number scheme
- Fixes README to be pypi compatible
- Improved sdist and bdist packaging support
- Changes to package information based on The Python Packaging Authority instructions
- Fix bug that produces traceback when running tests for the first time
- Fixes testing bug present on some distributions.
Far and away, working on the pyVmomi has been one of the most professionally satisfying projects of my career. That's chiefly because of how immediate the interaction and feedback from users of pyVmomi has been. In most other projects feedback from users of your code base has to navigate its way back to you over time, instead on pyVmomi the feedback has been immediate.
Part of this is due to the ease of public interaction that tools like github, freenode, pypi, and twitter (with ifttt automations) offers. I plan on evangelizing this working-style to other teams within VMware and your positive feedback can only help. For a developer it's a very rewarding way to work and hopefully for a customer it's also very satisfying.
Next week, I'll be working on our 2014.2 milestone and setting up to make a go at some more community samples. It should be noted that while pyVmomi itself is able to run just fine on Python 3, many of the samples are written assuming Python 2.7 ... this is fine since the two projects are decoupled.
The reason we keep the community samples repository separate from the core pyvmomi project is to allow for each project to exercise its own standards. The samples project is very loose while pyVmomi is run extremely tightly. That's a function of where on the stack each project lives. In general the deeper down the stack you go, the more rigid the project needs to run to ensure quality and stability for all the projects built on top of it.
More on the community project next week...
