I just spent the last few days snowboarding in Kirkwood, CA.
The Kirkwood Mountain Resort is tucked inside of the Eldorado National Forest, only about a 45 minute drive from the South Lake Tahoe area. It’s a quaint ski resort that in my opinion, gets the best snow in the immediate area.
As an added bonus, there back side of Kirkwood has no cell phone service so you can escape emails while carving up the mountains.
The next stop on my winter boarding tour will be Stowe, VT.
I don’t know if it’s just the last sprint before the end of the year for people, but there’s been a decent amount of buzz around software versioning lately. Maybe people (like Mirko Jahn) are just so frustrated with the status quo around versioning.
In the first case, the OSGi community has been blogging about the importance of semantic versioning in regards to the blah approach taken by the Jigsaw project. I find that Peter Kriens wrote an eloquent post about the importance of versioning in module systems like OSGi, especially when it comes to the semantics. In response to JSR 294’s versioning policy (vaguely Debian-like strings), Alex Blewitt has written a funny “JSR294 Fantasy Version Series” featuring a Linux and Roman Numeral versioning scheme. I highly recommend reading Alex’s blog series if you’re in need of a laugh.
I also learned today that the Groovy project is going through a modularization stage since the main Groovy JAR is now over 4MB and there’s a desire to break things apart (I wonder what monsters lurk under that big JAR). I hope the Groovy team considers a hard look at OSGi and also the importance of semantic versioning for its modules. Since it seems Groovy uses Maven as part of its build infrastructure, it should be easy to adopt OSGi with the upcoming Maven3 release and Tycho.
Ok, what about modularity and versioning outside the Java world? Well, to my surprise and excitement, there’s some activity in the Javascript space via the CommonJS group. The purpose of the CommonJS group is to build a JavaScript ecosystem for web servers, desktop and command line apps. As part of this effort, the group is developing a module and package system. While I still think they are a bit crazy, I’m happy to see that they are standardizing their versioning scheme (called SemVer) to include semantics.
If you look deeper into CommonJS and their module system, a lot of the metadata that they are defining for their modules map quite nicely to OSGi. Is it time that OSGi considers stepping out of the comfortable Java space and embrace modularity for other languages like JavaScript? There’s a lot of lessons the OSGi community can give to the modularity newcomers.
Has anyone seen anything else good when it comes to modularity and software versioning?
On a side note, sometimes I wonder if we need something like the Agile Manifesto but for Semantic Verisoning. I’d call it a Semantic Versioning Manifesto where people could sign it and support it. What do people think?
A couple weeks ago, I had the pleasure of visiting historic Vienna (which has the honor of having its city centre as a UNESCO World Heritage Site).
It was fun presenting at a local Eclipse DemoCamp at the TU Vienna university. The Eclipse community is definitely thriving in Vienna and I can’t wait to see how the DemoCamp turns out next year. In the spirit of my Eclipse evangelism, I tried to convince a certain code review project to find its new home at Eclipse.org; you’ll have to stay tuned in the coming weeks to see if I was successful or not 🙂
What did I like about Vienna besides the beautiful architecture and buildings?
First off, in the fine tradition of German speaking countries, the beer was delicious and plentiful.
On top of the great beer, I couldn’t get enough of the Christkindlmarkt’s and the copious amount of glühwein being served. I also learned what the turbo modifier means when it is applied to glühwein. It was definitely turbo…
I had a great time exploring the city with friends and the checking out the various Christkindlmarkt’s.
In the end, I hope to visit Vienna in the near future to explore the city a bit more. Hopefully by the next time I go, Anthony Bourdain will have had the chance to visit to give me a better idea of where to go 🙂
How should open source projects handle donations? And do it in a tasteful fashion?
I ask because I’ve been doing some work lately do expose the Friends of Eclipse program at Eclipse in a variety of ways. For example, I want to add a link on Eclipsepedia as we have on a variety of the Eclipse download pages.
I’m a fan of the Friends of Eclipse program because I believe in the power of community. All donations benefit the Eclipse community in some fashion from providing more bandwidth for users and committers to sponsoring Eclipse community events. The program is there as a way to contribute to Eclipse for people who may not have the time to become a committer but have the financial resources and desire to contribute. For awhile, I don’t think the program was very visible and that’s changed as the link has appeared on the download page. There are now over 1000 donations to the program! I see a future where we could get a considerable amount of support from the Friends of Eclipse program and help the Eclipse Foundation sponsor more events.
But is there a line that we can cross where it seems like we’re pan handling :)?
I tried to look at how other projects handle donations.
If you look at Wikipedia, their approach is to have everything front and center.
It seems to work for Wikipedia as they tend to have a fund raising drive model. Their users don’t seem to mind either. The Linux Foundation has a way to donate on its web page and they also have a program similar to the Friends of Eclipse where you can sign up for individual membership with some benefits.
How do other people view donation in the open source context? Is there a line to cross?
How do other open source projects do this?
The sad and final day has come for the Movember challenge. I’m proud to report that the Eclipse mommitters and I have raised over $3000 dollars for prostate cancer research. Donations are still possible!
As for my ’stache, here it is on the final day of reckoning.
On a side note, my ‘stache will be gone as of tomorrow and back next November 🙂
My inbox and twitter account has been under attack lately by Stephanie Meyer and her Twilight minions.
My current Google Alerts query for Eclipse-related news is this:
eclipse -lunar -aviation -mitsubishi -solar -twilight -heroes
It used to be much longer before and I’m trying to strike a balance now.
Anyone have a better one :)?
There was some activity on the JSR 294 mailing list this morning. The Jigsaw team came down from the mountains and has informed us that…
javac can compile source files belonging to modules inferred from the
modulepath and will enforce full module-private accessibility Real Soon
Now. Long-standing issues with bootstrapping the JDK have also been
addressed, such that modularized JDK libraries are used properly and
early in the build.The libraries are modularized by mechanisms in the Jigsaw module system
including but not limited to recursive virtual modules, per-method
dependencies, packages split across modules, and structured
arbitrary-length versions. Sun finds these mechanisms useful for
compatibly restructuring vanilla packages in the JDK, and believes they
are applicable to clients of the JDK also.Clearly, the Jigsaw model goes some way beyond “named and versioned
JARs”. How it overlaps with the OSGi model – designed for new, dynamic,
service-oriented applications – is not clear. Since both Jigsaw and OSGi
are defined in the first instance outside the JCP, it does not appear
that JSR 294 is well-positioned to define a module system that unifies
them. It would be a lowest-common-denominator design with
well-intentioned but irksome compromises. There has been no clear
support in the EG for the Simple Module System proposal, and I would
like to take it no further.
I just about stopped reading when I hit the “structured arbitrary-length versions” feature.
I dug a bit deeper in the Jigsaw Javadoc to see what this means exactly…
Nice… “Vaguely Debian-like version strings, for now.”
I had my rant on software versioning in general last week… this is a terrible idea in my book. Maybe I’m just in a bad mood because my inbox is under attack by Stephanie Meyer who happened to release a book with the same title as my favorite open source project. In module systems, version numbers should encode compatibility to keep us sane when developing and talking about things. Let me give you an example from OSGi land. Let’s say you’re writing an application and need to depend on log4j…
Require-Bundle: org.apache.log4j
You go to deploy your bundle and things work great. Your users are happy. Now you have a colleague take your bundle and deploy it into another system and you get a bunch of crazy exceptions. What happened? Well, first you didn’t specify a version range on your depending for log4j so basically your assumption is that your bundle would work with any version of log4j. At development time, you were using log4j 1.1 and the first system you were deploying to happened to use log4j 1.1 too. However, when your colleague went to reuse your bundle (since we can easily do that now since we have modules), things blow up because the system they went to deploy your bundle happened to have log4j 1.2… and the log4j development team unknowingly broke binary compatibility with the new release. To fix this problem… you can simply scope your depending on log4j…
Require-Bundle: org.apache.log4j;version=[1.1, 1.2)
Let’s use another example from OSGi land… commons collections. Let’s say you needed commons collections… you were developing with version 2.1 and you decided to be smart and scope you version range this time because you thought you learned your lesson.
Require-Bundle: org.apache.commons.collections;version=[2.1, 2.2)
Next what happened was that the commons collections development team released version 3.0 and declared it to be binary compatible with the 2.1 version. The potential environments your bundle can be deployed to is limited based on the scoped dependency above… even though your bundle would work fine in an environment where the commons collections 3.0 version was floating around. The ability to reuse your bundle was reduced.
The crux of the problem here is that you don’t know how to scope your version ranges and in particular… versions really don’t convey anything to you as a module developer. In OSGi land, there’s a four segment version and a mantra of encoding compatibility in your version number. Each segment of the version means something. To get a good idea of how to handle versioning on a large scale, we have a fantastic set of guidelines regarding versioning bundles at Eclipse. If everyone followed the same set of versioning guidelines, you can properly setup your dependencies and as a developer, you immediately can see meaning between what you’re developing against and what you may consume in the future.
My recommendation to the Jigsaw team would be to reconsider their stance on treating module versions like nothing. I would like to see binary compatibility encoding in version numbers and given the fact that Maven is moving to the OSGi versioning scheme… Jigsaw might as well also. It would be nice in Java if we had a consistent way to talk about the versions of software we develop for people to reuse.
Yesterday, I participated in the inaugural Dirty Du Half Marathon out in Smithville, Texas. Its been raining the past couple days so the morning started out wet and cloudy. The drive to Smithville is only about an hour from downtown Austin. Upon arrival, I noticed the course was going to be pretty muddy given the condition of the start line field.
The race organizers cautioned us that the course may be a bit muddy due to the weather with some potential deep streams to cross. I expected a muddy course with some streams to jump. What I didn’t expect was 13.1 miles of muddy trail perfection. I ended up sloshing through 24 inch deep streams, loose mud and slippery hills.
The race was never boring and I came out the other end covered in mud. In fact this was the most enjoyable trail race I’ve ever run due to the great course and mix of perfect muddy conditions. I managed to finish the race 4th overall (3rd in my gender group) with a time of 1:51ish. My prize?
A New Belgium beer glass and box of delicious mountain mix Cliff Mojo bars.
I feel sorry for the mountain bikers who had to wade through that course this morning. It’s interesting to note Lance Armstrong holds the mountain bike course record with an impressive time of 1:36:05! I don’t think that record will be broken this morning given the dirty conditions. In the end, I want to thank the race organizers for putting on a great event. I hope that the trail half marathon shows up on the agenda again next year and that more people show up. Don’t let a little rain scare you from good time.
I am on day 20 of growing a moustache for Movember. I have decided to go against my stylist’s best wishes and help raise money for prostate cancer research with my fellow Eclipse committers. We have raised over $2300 dollars so far! This week’s update includes a new splash screen for Eclipse (thank you Ian Bull).
As for my ‘stache, here it is on day 20.
Solid progress. Please donate!
Alright, I have to vent and go on a diatribe as its been awhile.
I was in the process of updating my iPhone and was greeted with these updates.
1.34? 1.7f? Why does Apple even bother showing the version number. I don’t even know what version of the software was previously installed. As a user, I only really care if there’s an update and what is included in that update. That’s it.
The way software engineers treat version numbers is sad. Since the inception of software, we haven’t been able to come up with a reasonable versioning scheme that can be shared across technologies. Even worse, versions really mean nothing. On top of that, we confuse marketing version numbers with internal software version numbers. Here are some examples of what I’ve come across.
Let’s start with Java. 1.0.3, 1.1.2, 1.4.2, 1.5.0, 1.6.0? Why both with the “1” in the version number?
Next up we have is Windows… 3.1, 2000, XP, ME and 7. Awesome.
I remember when Netscape magically went from version 4 to 6. You know, we didn’t really need a version 5 because IE was already at version 6. We can’t let our competitors out version us.
In Linux… 2.3, 2.4.0, 2.6.8, 2.6.8.1… it’s cool when you can start adding version segments. Linux also seems to suffer the Java problem where the first digit is meaningless… maybe Linus’ favorite number is 2. On the bright side, the second segment in the version number at least signifies whether the code is considered stable or not. I’ll give bonus points to Linux for that.
SmallEiffel… -0.87, -0.79, -0.74… nice… software versions that start on the negative scale and apparently count down to zero.
In areas where modules exist and there’s a goal of reusable components (think OSGi and Maven), there’s a standard version scheme with a recommended policy on how to handle version changes. The only problem is that not everyone follows the scheme given their experience where version numbers mean nothing. It also doesn’t help that version schemes may be different amongst similar component technologies.
In the end, there really needs to be two types of versions, one for the marketing department and one for the development department. Confusing the two types is bad. It’s good to see that I’m not the only one that feels like this, there’s some funny commentary by Jeff Atwood on versioning.
Shame on us in the software industry for letting this crap continue.
