Twitter github

Releasing in Open Source and at

Releasing software is a bit of an art form and everyone has different philosophies, especially in the realm of open source. For some people, releasing something every week is critical, some people want to release consistently on-time and others simply never ship. We also have to be mindful that releasing software means different things in different communities. In mature open source communities like Apache and Eclipse, you’ll find more formal processes to deal with when announcing a release, whether it’s incubating or mature. I have a personal philosophy that shipping is everything, probably a remnant of my heavy involvement on the Eclipse platform team, but that’s a topic for another day.

Inside the community, there’s been some discussion lately about scheduling releases. Historically, the Eclipse platform ships a major release every year (triggers a release review as part of the EDP) with six-week milestones in between. Also, the Eclipse platform project aligns itself with the annual simultaneous release (e.g., Indigo). I think this works fine for the platform project because it’s extremely mature and dependent on by a lot of consumers. However, I would love to see the platform release more than once a year, but I haven’t had enough time to think about how to do that without being very disruptive. It is something the project leadership should be thinking about as we move into the 4.X Eclipse stream.

Since the Eclipse platform project is very prominent, a lot of other projects tend to align their releases with the platform. I think this is wrong method to choose your release schedule, especially if you’re a young project. Actually, some people I have talked to think that they only have to release once a year, which is wrong as the EDP doesn’t impose any major time restrictions on you releasing. I think each project should release according to its maturity level and adopters needs. For example, let’s look at the Mylyn project’s release history…

  • Mylyn 3.6.2 (February 24, 2012 – Indigo SR2)
  • Mylyn 3.6.1 (September 23, 2011 – Indigo SR1)
  • Mylyn 3.6 (June 22, 2011 – Indigo)
  • Mylyn 3.5 (March 16, 2011)
  • Mylyn 3.4.3 (February 25, 2011 – Helios SR2)
  • Mylyn 3.4.2 (September 24, 2010)
  • Mylyn 3.4.1 (August 4, 2010 – Helios SR1)
  • Mylyn 3.4 (June 23, 2010 – Helios)
  • Mylyn 3.3 (Oct. 26th, 2009)
  • Mylyn 3.2 (June 24, 2009)
  • Mylyn 3.1 (March 4, 2009)
  • Mylyn 3.0 (June 25, 2008)
  • Mylyn 2.3 (Feb. 27, 2008)
  • Mylyn 2.2 (Dec. 19, 2007)
  • Mylyn 2.1 (Sep. 28, 2007)

If we notice a pattern, Mylyn tends to release about four times a year and tries to align itself with the annual release train. Another example is the EGit/JGit projects…

  • EGit/JGit 0.7.1 (Mar. 22, 2010)
  • EGit/JGit 0.8.1 (Jun. 2, 2010 – Helios)
  • EGit/JGit 0.9.1 (Sep. 15, 2010 – Helios SR1)
  • EGit/JGit 0.10.1 (Dec. 17, 2010)
  • EGit/JGit 0.11.1 (Feb. 11, 2011 – Helios SR2)
  • EGit/JGit 0.12.1 (May. 2, 2011)
  • EGit/JGit 1.0 (Jun. 1, 2011 – Indigo)

The EGit/JGit project tends to release every few months and tries to align itself with the annual release train.

What’s your ideal release schedule? If you’re an project, why don’t you release more often?

  • Dave Orme

    I, too, have been influenced both by the Agile community (“software should ideally always be in a shippable state”) and by the pragmatism of the Eclipse Platform team, which I would paraphrase as “shipping is painful so do it often, but not so often that we discourage experimentation; a bit of entropy is healthy as long as we pay back our technical debts regularly”

    I’ve used six week release cycles like Platform in my own work because I have found it to be a long enough time to get interesting work done but keeps me from letting things out of hand.

    Dave Orme

  • Stephan Herrmann

    Hi Chris,
    In your listing of releases we do notice a pattern: 
    Mylyn evolves bottom-to-top whereas [EJ]Git are evolving top-down 🙂

    In my time with and at Eclipse I got very much used to the 6 week heart beat.
    If we all agree on this heart beat I wouldn’t care too much about frequency
    of releases, but I think one of the interesting variables is: stability.

    If every 6 weeks we do publish something, how do we tell users what to expect?
    Is a milestone a bleeding edge artifact only for dare-devils?
    Who should consume weeklies, nightlies?
    Isn’t this all about communication with the users?

    I could see some meta data being attached to every “release”:
    – severity of bugs fixed (are security issues affected?)
    – amount of new features
    – risk for adopters
    All these aren’t booleans but ratings on a scale.

    From there on let users decide what they consider a release worth upgrading to.
    They will have different thresholds.

    All SimRel projects agree to minimize “risk for adopters” at least once a year.
    Between coordinated releases each project will opportunistically decide how much
    deviation from that state they allow for intermediate versions.
    Should we call all intermediate versions “releases”?
    I wouldn’t care too much. If the status of each version is transparent,
    users will figure out.