There has been some great discussion here,
and some similar ideas to what were discussed at the Planning Council F2F
earlier this year . Many Eclipse projects are already doing 3-6 or even
more releases a year, so ideas about how to bring those together and get
them out to end-users are worth talking about. My current view is that
we are already slowly evolving from the "one feature release a year"
to three release windows a year (June, September, February). Some projects
use those release windows for maintenance, others use them for new "feature
releases". This makes sense as our projects are very diverse and the
needs of different projects' consumer communities differ. We discussed
this briefly in last week's Eclipse Project PMC and we currently think
the 1+2 rhythm currently works well for the Platform project, but there
is nothing stopping other projects from adopting a more frequent feature
release cadence. Maybe we need to acknowledge this reality and change the
names of the September/February releases to indicate they are not purely
service releases (and yes, Spring/Summer/Fall are not the right names either).
As for the specific idea of a December
release, I admit I'm not wild on it. The last couple of weeks of December
is really a poor time to be shipping software, both from perspective of
people being on holidays, and from a marketing perspective it's hard to
get anyone's attention at that time of year. Perhaps a bit more achievable
is moving the September release to end of October, to make it a consistent
pattern of release windows every four months. That also lines up nicely
around EclipseCon Europe which is a big marketing and education opportunity
if you're doing a release at that time of year. Again, not every project
would need to use these windows for feature releases. A project could make
every second window a feature release and use the in-between ones for maintenance.
Or 2 feature releases + 1 maintenance release, etc. Again this is something
projects are already moving towards and it is mainly a matter of socializing
and outreach about what the Sept/Feb releases are doing. The next natural
step from 3 release windows a year would be quarterly releases but this
is a bigger step for projects and the community to make.
Konstantin's thought experiment about
continuous aggregation is also really interesting. The key problem here
is workload - our current aggregation is too error prone, unrepeatable,
and time-consuming to add even more aggregations right now. It currently
seems to take several full days of someone's time to nurse an aggregation
through to successful completion. Part of this can probably be removed
through better tooling and automation, but some of it may be the natural
cost of getting so many millions of lines of fast moving open source code
lined up, built, and tested. I think we need to improve infrastructure+process
before we can increase how often we release aggregated content.
The other question for the continuous
aggregation idea is to ask who is the target audience for it. If
the goal is to get new features into the hands of users more quickly, then
I think using the current nearly-monthly milestone aggregation is the better
path. This gets new features out even faster, and also means that users
get exposure to features early enough that projects can incorporate feedback
before it is too late. The Chrome/Firefox Beta channel concept is very
popular with developers - they are eager to get their hands on new stuff
and are often willing to sacrifice a bit on quality to get it. The Eclipse
community is much smaller but I still think there would be interest if
we get the word out and set the right expectations. Personally I am never
using anything older than the last milestone and overall stability is quite
On the other hand if the target audience
for continuous aggregation is commercial adopters, I think it is much less
valuable. What commercial adopters really value is the schedule alignment,
and whether there is an aggregate repository and EPP packages or not is
a relatively minor concern. Anyone building against Eclipse would likely
not want to target a repository that is shifting every month in unpredictable
ways - they generally want to control the timing of adoption by consuming
from the individual repositories of single project releases.
Anyway, that was a bit more verbose
and rambling than I intended, but that's my current input to the discussion...
Doug Schaefer <dschaefer@xxxxxxx>
07/02/2013 03:31 PM
6 month release cycle
We have a discussion going in the CDT community
and we are currently planning out how to achieve a 6 month release cycle.
The feeling is that we need to get new features out faster to our users.
The year long wait we currently have is making releases sluggish and I
fear it's slowing down growth in our community. A 6 month cycle should
infuse us with a little more energy, so goes the hope.
I mentioned CDT's plans on twitter and a
number of senior members of our larger Eclipse community thought it might
be a good idea for other projects at Eclipse and maybe for the train itself.
And I think so too.
Instead of continuing that discussion on
twitter, which is fun and everything, I thought we should bring that to
a greater audience and see what other projects thought and whether it's
something we should bring to the Planning Council and the rest of the EMO.
I know there are a number of projects already
releasing off stream during the year, but bringing things together more
often might be a help to many others. But I'd like to hear your thoughts