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 eclipse.org 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 eclipse.org 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 eclipse.org project, why don’t you release more often?