Libcloud and the road to 1.0 release

Back in September of 2011, I was a guest on FLOSS Weekly where I was interviewed about Libcloud.

If you are not familiar with FLOSS Weekly, it’s a weekly podcast (hence the name) about free and libre open source software. I have been listening to to it for a long time (it’s a great way to spend time while you run errands / shop for groceries / bike to work) and one of my favorite things is that it covers a very wide range of guests and topics. Guests range from new comers to open source word to people with 15+ years of experience and a long open source contribution history. Some goes for projects. They range from small hobby projects you might never heard about to popular projects with very large communities and ecosystems such as Arduino and OpenStack Swift.

The road to 1.0

Anyway, lets get back on topic.

One of the questions was how stable Libcloud is and when users can expect a 1.0 release. At that time, some of the APIs such as DNS and storage were added just recently, but compute API has been stable for quite a while and used in production in multiple places.

My answer was something along the lines that for the main part, Libcloud already is production ready and 0.1 versioning scheme is just an artifact left over from the past and 1.0 version should hopefully be released some time next year.

It has been more than 2 years since then and we have made numerous releases during that time, but a version 1.0 still hasn’t been released yet.

You might ask why. The closest reason for that is that a documentation was lacking and we just simply hadn’t made the switch yet.

New documentation which is available at https://libcloud.readthedocs.org.

Documentation situation has been improving lately, so a while back I thought it’s finally time to start working on a 1.0 release.

1.0, does it even matter?

Some of you might ask why switch to 1.0 and not just continue with 0.1 series?

There are multiple reasons for that:

  • 1.0 release indicates production readiness to a lot of people. I’m personally more of a rolling release guy and believe that the whole “production ready” concept is often misleading and the switch is usually made purely out of marketing and political reasons and not technical ones. In any case, a lot of users still associate 1.0 with production readiness so it makes sense for us to switch and indicate them that Libcloud is safe to be used in production.

  • Move to 1.0 will finally allow us to use semantic versioning. As noted above, current versioning scheme is mostly and artifact from the past. Using semantic versioning will make it easier for our users to understand what is going on and know what to expect with each release. If you want to know other reasons, see this mailing list thread.

An example of semantic versioning scheme. Source: http://www.aosabook.org/en/eclipse.html

Some of you might also say that this switch seems kinds arbitrary. That is true, but as noted above, base APIs have been stable for a long time and at this point, we should just do it.

On top of that, Linux kernel did a similar thing with transition from 2.6 to 3.0 and if Linux kernel can do it, we can do it as well :P

Road to 1.0

I would say that at this point the road to 1.0 is pretty shallow and my goal is to get the release out some time in the next couple of months.

We are currently working on a 0.14.0 release. This releases includes some pretty big changes and improvements and will most likely be a last release with backward-incompatible changes before the 1.0 one.

One of the more important changes this release bring is improved support for providers with multiple regions. For more, see Upgrade notes and CHANGES file.

And as far as backward-incompatible changes go, we have doing our best to avoid them as much as possible, even before the 1.0 release. Sadly that is not always possible and we did manage to have some backward incompatible changes in the past, but all of those changes very small and non-invasive. We also didn’t press users to update their code as soon as possible and we supported old (deprecated) way of doing things for a long time to make a transition easier.

Another thing which I would also like to see done before 1.0 release is an improved and more user-friendly website. It is something which has been on my todo for a long time and I have even started to work on it in the past, but I was always distracted by other things and never made much progress.

Sneak peek of a new website. Keep in mind that this is a very early draft which is likely to change in the near future.

In any case, Jerry recently started working on an improved design based on Bootstrap 3. Once the new design is ready, it should be a fairly easy and smooth ride from then on.

How can I help?

As always, any kind of help and contributions are welcome and appreciated. One of the things we need the most help with at the moment is documentation and testing of the 0.14.0 release once it becomes available.

For information on how to contribute, see this page.

So, when?

As noted above, two main pre-requisites for the 1.0 release are a new website and a 0.14 release. Both of those things should be available in the near future.

We obviously do a lot of testing and have a fairly comprehensive test suite, but nothing is perfect and sadly, some bugs almost always manage to get overlooked.

I imagine this will also be the case with 0.14.0 release and even more so since it includes a large number of changes and improvements.

Because of that, I want to give 0.14 enough time in the wild before preparing a 1.0 release. This means you can expect 1.0 release around 6 - 12 weeks after 0.14 becomes available.