Meet OpenSpending version 0.13.0Outdated Content Warning: This content refers to an older version of OpenSpending. See here for information about the next version of OpenSpending and ways to contribute.
This is going to be a slightly technical post (and has already been posted to the developer mailing list), but still it’s an important change so everyone is encouraged to read it. If you don’t understand something, then that’s just fine, it probably does not have anything to do with you and you can skip it.
For a long time we have had version 0.11 of OpenSpending (since October 2011). We then for a short time had a version 2.0 alongside our 0.11 (we had not reached 2.0 so it was kind of confusing, but it snuck in with the re-theme of our docs back in January – 2.0 came in according to the python convention while OpenSpending (version 0.11) had its own convention).
This has all now been corrected and we redid how versions are handled (this happened about a month ago). We now do versioning as recommended by Zooko (probably best known for Tahoe-LAFS and Zooko’s Triangle). This is a nice mix of the two conflicting versions we had so this confusion should not happen again.
While making those changes and removing the erroneous 2.0 I decided it was time to bump up the version to version 0.12.0 without announcing anything per se. Versions aren’t as big of a deal in our continuous deployment setup (meaning we deploy changes as soon as they’re ready) so nobody is really looking at the versions.
But that’s not entirely correct. Versioning, when done properly, can help both users and new contributors (and ourselves) better understand what is happening on the project and allows us later on to introduce backwards incompatible changes in a way that we can prepare users and contributors for (this is something we should always avoid, but still a safety pin worth having). Perhaps most importantly, it helps us plan for the future with milestones. What do we want to see in version 1.0.0 or 1.5.0 etc.?
We’ll be using the Semantic versioning system, introduced by Tom Preston-Werner (who created Gravatar and is one of the founders of Github). The versioning syste is a convention had been used before by numerous projects, but never officially with explicit meaning like what Tom did. In the past it was more of a project-members-decided-what-the-numbers-between-the-dots-mean basis).
In this versioning system we have the <major>.<minor>.<patch> where major versions are backwards incompatible, minor are compatible changes, and patches are bug fixes etc (goals along the way to our next minor/major version).
…and with that I’m going to introduce backwards incompatible changes in a minor version by introducing version 0.13.0 (oh isn’t it wonderful how you can break rules as soon as you set them). OpenSpending version probably won’t update that frequently in the coming months, but as more contributors jump on board and more pull requests start pouring in we’ll get closer to the open source development mantra: “release early, release often”.
USERS HEADS UP: This is the important thing for you to know. We are going to have versions and as long as the number in the middle, or the last numbers change, you’ll just be seeing a better OpenSpending platform. When you see the first number change you’ll have to watch out. Things you expected to work might not work. Don’t worry though these first number editions (major version) will not be thrown on you just like that but we’ll prepare for them and let you know well in advance so you can prepare yourselves for the change if it affects you.
We’ve done a lot of changes over the past few months with a lot of help from the community, especially on the code cleanup front. We are now fully pep8 compliant and pyflakes error free (meaning the code easier to read and less unnecessary things in the code).
We should all be very thankful for the tremendous work of Jorge C. Leitão, Randal Moore, Justin Duke, and garethpdx who have helped us clean up our code base. There’s still a lot of work to be done, but thanks to Jorge, Randal, Justin and garethpdx we can all now feel it, the code can be tamed! Thanks all of you!
In those changes I felt I had to make a substantial change to how celery worked in OpenSpending. We did a lot of weird magic to hook celery into paster as a command and we had to do this strange (unused) import:
from openspending.command import celery
to set some configuration variables in order for celery to work. That has now been scrapped and we have a new version of celery in OpenSpending (version 3.1.11).
Celery is no longer managed via paster, we can now use the celery commandline tool that comes with celery to launch our workers. Instead of manually setting a lot of stuff in a config file we can now just do something like:
celery -A openspending.tasks -p <ini-file> -l info worker
(The -p option there is still needed to provide the pylons ini file, and is an openspending extension of celery, since other configurations, such as the database are still managed by config files).
More information about the celery tool and how it can launch workers here:
That’s the big incompatible change which sparked off version 0.13.0. This is not a user facing change so I decided against a major version, but for those of us that have a development version that’s a change which is pretty important to know about.
With this announcement of a new versioning system and the new version I think it is in order to ask the community (please reply on our mailing lists so we can have a great discussion about this):
- What would you like to see in version 0.14.0?
- What would you like to see in version 1.0.0?
Need help in figuring out what to suggest? Just visit our issue tracker for some ideas.
Welcome to the new versioned OpenSpending. I hope you’ll all enjoy :-)