Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » General (non-technical) » Eclipse Foundation » More frequent releases needed
More frequent releases needed [message #21510] Wed, 20 July 2005 11:47 Go to next message
Ed Burnette is currently offline Ed Burnette
Messages: 279
Registered: July 2009
Senior Member
The Eclipse Platform seems to be on a yearly release schedule right now:

Table 1: Current schedule
2.0 - June 2002
2.1 - March 2003
3.0 - June 2004
3.1 - June 2005
(projected) 3.2 - June 2006

This is too slow for many reasons I'll get into in a moment. I propose
the that the release schedule be changed to have a production release
every 6 months. So:

Table 2: Proposed schedule
3.1 - June 2005
(proposed) 3.2 - December 2005
(proposed) 3.3 - June 2006

The "3.3" release in Table 2 would have roughly the same features as the
"3.2" release in Table 1. (Of course these release numbers are just
illustrative, I don't know whether it would be called "3.3" or "4.0" or
something else.)

There are several reasons I'm proposing this. First, the vast majority
of users will only download and use the production release (see the
recent thread "Download page should highlight latest milestone" if you
want proof of that). This could be due to corporate policy or personal
preference. Because of this, many add-in providers will only target the
production release. The same goes for some non-Platform projects within
eclipse.org itself. Some are reluctant to fix problems in their projects
that manifest themselves in pre-release versions, preferring to wait
until the production version is out. Users and downstream developers
would benefit from having access to new functionality and fixes quicker.

Second, yearly releases are not the norm for open source products. Look
at other IDEs, platforms, libraries, and tools and you'll see they
release product much more quickly than this. Of course Eclipse is a big
system so nobody would suggest having a production release every week or
even every 6 weeks, but I feel that 6 months is a good compromise.

Next, it's been proven that more frequent releases improve the quality
of the software. We already see that with Eclipse's use of
Milestone/stable builds which are like mini-releases. The quality is
lifted up as the Milestone approaches, so there's not so far to go for
the Production build. Also if you reduce the time between when a
developer writes a piece of code and a user tries it out, you get better
feedback and higher productivity.

More frequent releases reduce stress on the developers. Currently at the
end of a cycle there's always a big push to get your favorite feature
and API to go into the Production because it'll currently be a whole
year before the opportunity arises again. I've watched this happen in
each of the last three releases. With twice-a-year releases it's not so
long a wait.

Finally, and perhaps most importantly, it would give the Platform
development teams and committers a winter break as well as a summer
break to enjoy. :)
Re: More frequent releases needed [message #21600 is a reply to message #21510] Wed, 20 July 2005 20:09 Go to previous messageGo to next message
Eclipse User
Originally posted by: bob.objfac.com

Erich Gamma's view -
http://www.artima.com/lejava/articles/eclipse_culture.html - seems to be
that Eclipse ships continuously, and your view seems to be it only ships
once a year. There's justice to both views. Much of what ships
continuously is only half-done and buggy. It might be good for everyone
to be thinking about what can be finished and polished in a little over
four months rather than a little under ten months.

However, if I follow Gamma's thinking correctly more frequent releases
would increase stress on developers, because it would require two "end
games" per year instead of just one. And, unless you've got some quality
magic that can shorten an end game, you'd have three months a year just
devoted to release process.

Bob Foster
http://xmlbuddy.com/


Ed Burnette wrote:
> The Eclipse Platform seems to be on a yearly release schedule right now:
>
> Table 1: Current schedule
> 2.0 - June 2002
> 2.1 - March 2003
> 3.0 - June 2004
> 3.1 - June 2005
> (projected) 3.2 - June 2006
>
> This is too slow for many reasons I'll get into in a moment. I propose
> the that the release schedule be changed to have a production release
> every 6 months. So:
>
> Table 2: Proposed schedule
> 3.1 - June 2005
> (proposed) 3.2 - December 2005
> (proposed) 3.3 - June 2006
>
> The "3.3" release in Table 2 would have roughly the same features as the
> "3.2" release in Table 1. (Of course these release numbers are just
> illustrative, I don't know whether it would be called "3.3" or "4.0" or
> something else.)
>
> There are several reasons I'm proposing this. First, the vast majority
> of users will only download and use the production release (see the
> recent thread "Download page should highlight latest milestone" if you
> want proof of that). This could be due to corporate policy or personal
> preference. Because of this, many add-in providers will only target the
> production release. The same goes for some non-Platform projects within
> eclipse.org itself. Some are reluctant to fix problems in their projects
> that manifest themselves in pre-release versions, preferring to wait
> until the production version is out. Users and downstream developers
> would benefit from having access to new functionality and fixes quicker.
>
> Second, yearly releases are not the norm for open source products. Look
> at other IDEs, platforms, libraries, and tools and you'll see they
> release product much more quickly than this. Of course Eclipse is a big
> system so nobody would suggest having a production release every week or
> even every 6 weeks, but I feel that 6 months is a good compromise.
>
> Next, it's been proven that more frequent releases improve the quality
> of the software. We already see that with Eclipse's use of
> Milestone/stable builds which are like mini-releases. The quality is
> lifted up as the Milestone approaches, so there's not so far to go for
> the Production build. Also if you reduce the time between when a
> developer writes a piece of code and a user tries it out, you get better
> feedback and higher productivity.
>
> More frequent releases reduce stress on the developers. Currently at the
> end of a cycle there's always a big push to get your favorite feature
> and API to go into the Production because it'll currently be a whole
> year before the opportunity arises again. I've watched this happen in
> each of the last three releases. With twice-a-year releases it's not so
> long a wait.
>
> Finally, and perhaps most importantly, it would give the Platform
> development teams and committers a winter break as well as a summer
> break to enjoy. :)
Re: More frequent releases needed [message #21645 is a reply to message #21600] Thu, 21 July 2005 16:30 Go to previous messageGo to next message
Ed Burnette is currently offline Ed Burnette
Messages: 279
Registered: July 2009
Senior Member
No, look at it this way. There's a little 'end game' for each I build, a
bigger one for the M build, and even bigger for the production release.
The length and stress of an 'end game' is directly proportional to how
long it has been since the last one of that type.

Bob Foster wrote:
> However, if I follow Gamma's thinking correctly more frequent releases
> would increase stress on developers, because it would require two "end
> games" per year instead of just one. And, unless you've got some quality
> magic that can shorten an end game, you'd have three months a year just
> devoted to release process.
>
> Bob Foster
> http://xmlbuddy.com/
Re: More frequent releases needed [message #21690 is a reply to message #21645] Thu, 21 July 2005 17:00 Go to previous messageGo to next message
Eclipse User
Originally posted by: merks.ca.ibm.com

Ed,

From my personal experience, much of the 'end game' overhead is fixed
because rather than being proportional to how much new work has been
done, it's proportional to the total amount of function provided, all of
which needs (re)testing. My feeling is that more releases will increase
the burden, stress, and overhead, and will make it harder to tackle
larger issues. This idea gets a definite -1 from me...


Ed Burnette wrote:

> No, look at it this way. There's a little 'end game' for each I build,
> a bigger one for the M build, and even bigger for the production
> release. The length and stress of an 'end game' is directly
> proportional to how long it has been since the last one of that type.
>
> Bob Foster wrote:
>
>> However, if I follow Gamma's thinking correctly more frequent
>> releases would increase stress on developers, because it would
>> require two "end games" per year instead of just one. And, unless
>> you've got some quality magic that can shorten an end game, you'd
>> have three months a year just devoted to release process.
>>
>> Bob Foster
>> http://xmlbuddy.com/
>
Re: More frequent releases needed [message #21734 is a reply to message #21690] Thu, 21 July 2005 17:04 Go to previous messageGo to next message
Eclipse User
Originally posted by: richkulp.us.NO_SPAM.ibm.com

I agree Ed. And it actually doesn't even have to do with the amount new
function. We have to regression testing too, and that is the same no
matter how much or how little function is added. The month (at least)
before a release is hell around here as we do testing and regression
testing and retesting.

Ed Merks wrote:
> Ed,
>
> From my personal experience, much of the 'end game' overhead is fixed
> because rather than being proportional to how much new work has been
> done, it's proportional to the total amount of function provided, all of
> which needs (re)testing. My feeling is that more releases will increase
> the burden, stress, and overhead, and will make it harder to tackle
> larger issues. This idea gets a definite -1 from me...
>
>
> Ed Burnette wrote:
>
>> No, look at it this way. There's a little 'end game' for each I build,
>> a bigger one for the M build, and even bigger for the production
>> release. The length and stress of an 'end game' is directly
>> proportional to how long it has been since the last one of that type.
>>
>> Bob Foster wrote:
>>
>>> However, if I follow Gamma's thinking correctly more frequent
>>> releases would increase stress on developers, because it would
>>> require two "end games" per year instead of just one. And, unless
>>> you've got some quality magic that can shorten an end game, you'd
>>> have three months a year just devoted to release process.
>>>
>>> Bob Foster
>>> http://xmlbuddy.com/
>>
>>

--
Thanks,
Rich Kulp
Re: More frequent releases needed [message #21779 is a reply to message #21690] Thu, 21 July 2005 22:03 Go to previous messageGo to next message
Eclipse User
Originally posted by: pascal.ibm.canada

-1
Ed Merks wrote:
> Ed,
>
> From my personal experience, much of the 'end game' overhead is fixed
> because rather than being proportional to how much new work has been
> done, it's proportional to the total amount of function provided, all of
> which needs (re)testing. My feeling is that more releases will increase
> the burden, stress, and overhead, and will make it harder to tackle
> larger issues. This idea gets a definite -1 from me...
>
>
> Ed Burnette wrote:
>
>> No, look at it this way. There's a little 'end game' for each I build,
>> a bigger one for the M build, and even bigger for the production
>> release. The length and stress of an 'end game' is directly
>> proportional to how long it has been since the last one of that type.
>>
>> Bob Foster wrote:
>>
>>> However, if I follow Gamma's thinking correctly more frequent
>>> releases would increase stress on developers, because it would
>>> require two "end games" per year instead of just one. And, unless
>>> you've got some quality magic that can shorten an end game, you'd
>>> have three months a year just devoted to release process.
>>>
>>> Bob Foster
>>> http://xmlbuddy.com/
>>
>>
Re: More frequent releases needed [message #21824 is a reply to message #21734] Fri, 22 July 2005 11:18 Go to previous messageGo to next message
Eclipse User
Originally posted by: eclipse3.rizzoweb.com

Rich Kulp wrote:
> I agree Ed. And it actually doesn't even have to do with the amount new
> function. We have to regression testing too, and that is the same no
> matter how much or how little function is added. The month (at least)
> before a release is hell around here as we do testing and regression
> testing and retesting.

I like the original suggestion, and the comment above typifies why
XP/agile strategy should be applied more here, not less.
If it hurts to do a full release, that doesn't mean you should
postpone/avoid the pain. Instead, do something to fix the pain, make it
less painful. I see the end game as a place where the Eclipse
development culture has room for improvement.

IOW, it should not be so painful - since it is, THAT is the problem to
be addressed. Making releases more frequent is a really good way to
motivate yourselves to find better & more efficient ways to prepare
releases than what exists currently.

Come on guys, be brave, be (more) agile. Continue setting an example
that we all can appreciate/learn from/point to!

And keep up the good work.

Eric

BTW, has anyone bothered to create a Bugzilla entry for this? I think it
should be "persisted" that way so the topic gets proper attention.
Re: More frequent releases needed [message #21869 is a reply to message #21690] Sat, 23 July 2005 00:04 Go to previous messageGo to next message
Ed Burnette is currently offline Ed Burnette
Messages: 279
Registered: July 2009
Senior Member
Ok, even if I'm wrong about the time & stress level argument, that was
really the weakest one. How about the other reasons I sited, especially
the first two?

1. Users only downloading release versions (and implications that has),
2. Yearly not the norm for OSS projects (this is hurting Eclipse with
respect to certain other projects), and
3. Quality (due to more timely feedback and 'tenting').

Ed Merks wrote:
> From my personal experience, much of the 'end game' overhead is fixed
> because rather than being proportional to how much new work has been
> done, it's proportional to the total amount of function provided, all of
> which needs (re)testing. My feeling is that more releases will increase
> the burden, stress, and overhead, and will make it harder to tackle
> larger issues. This idea gets a definite -1 from me...
Re: More frequent releases needed [message #21914 is a reply to message #21869] Sat, 23 July 2005 08:48 Go to previous messageGo to next message
Eclipse User
Originally posted by: merks.ca.ibm.com

Ed,

I'm not sure that the first point is a fact backed by data rather than
an assertion. The web master would be in a good position to provide the
facts. When we were tracking EMF downloads ourselves, the download rate
of each integration build was very high. And it seems to me that the
Eclipse milestones tended to create noticeably heavy traffic at Eclipse.

I'm not so easily swayed by whether other folks jump off a bridge or
not. ;-) It's best to understand the reasons and to choose what's best
based on those, rather than to look to your left and right and do what
you see there without understanding why. I.e., don't follow, lead.

As you say, users who don't help us test our builds before the release
will not be helping contribute towards the quality of the release. But
that would remain the same problem no matter how often the release.
Your argument is that it would be less of a problem the more releases we
squeeze in but then I suppose the question needs to be asked, what is
the optimal number? If more is better, why not every three months?
(And you might ask, if less is better, why not every two years?)

If users don't contribute to the quality of a release, they'll find
their problems aren't fixed in that release, so they'll be waiting for
the next one, and if that takes a long time, they'll feel much more
compelled to change their behavior. Helping test during the final
stages of a release, and having that not become burdensomely often, may
help encourage better behavior.

Although for many of us, contributing to Eclipse is what we get paid
for, most of us also make significant personal contributions towards the
success of what's available at Eclipse. Increasing the burden on
volunteer workers, without associated increases in resource or a
reduction in the volunteer aspect of the work, isn't so easily justified
simply because we all want more and better. Of course we all want more
and better quality releases, but if we don't shoulder the burden, we
aren't really in a position to insist on it. Those who shoulder the
burden ought to decide the level of burden that can be carried...


Ed Burnette wrote:

> Ok, even if I'm wrong about the time & stress level argument, that was
> really the weakest one. How about the other reasons I sited,
> especially the first two?
>
> 1. Users only downloading release versions (and implications that has),
> 2. Yearly not the norm for OSS projects (this is hurting Eclipse with
> respect to certain other projects), and
> 3. Quality (due to more timely feedback and 'tenting').
>
> Ed Merks wrote:
>
>> From my personal experience, much of the 'end game' overhead is fixed
>> because rather than being proportional to how much new work has been
>> done, it's proportional to the total amount of function provided, all
>> of which needs (re)testing. My feeling is that more releases will
>> increase the burden, stress, and overhead, and will make it harder to
>> tackle larger issues. This idea gets a definite -1 from me...
>
Re: More frequent releases needed [message #22093 is a reply to message #21869] Tue, 26 July 2005 14:57 Go to previous messageGo to next message
Mike Milinkovich is currently offline Mike Milinkovich
Messages: 258
Registered: July 2009
Senior Member
This pretty much has a -1 from me, for the following reasons:

1. We already have *lots* of users who download milestone builds. Obviously
not as many as a production release, but lots. The existing six-week project
"heartbeat" that provides regular milestones which people download and
provide feedback on has evolved based on several years of experience.

Denis is on vacation this week, but we can just look at our bandwidth charts
and easily pick when the milestone builds are released by the download
traffic.

2. I personally have zero exposure to other OSS projects which are impacted
by our community's current annual cycle. Do you have any specific examples
of where this is negatively impacting the Eclipse community?

3. I do not see any evidence that more cycles will increase quality. It may
be largely semantics, but the teams practice agile methods already in the
sense that each milestone build does have a mini-end-game associated with
it. Testing and testing often happens today. Eclipse already has a pretty
enviable track record on quality, so claiming that quality will improve
because of this suggestion is IMHO pure conjecture.

4. And this one is my personal biggie.....The release cycle may be longer
than some other OSS projects, but Eclipse has been almost uniquely
successful in creating a commercial ecosystem around it. I doubt very much
that the commercial product builders that ship on top of the Eclipse
platform are eager to be placed into a situation where they will be expected
to ship more often. One key benefit of the way things are done today is that
it is *predictable*. Companies and projects know that they can base their
product plans on Eclipse releases with the calming assurance that the teams
have an impressive track record of hitting their dates. Perturbing a working
system would result in added risk for a great many companies who build
products on top of Eclipse.

I personally have always believed that if it ain't broke, don't fix it.

I would expect that before the committer community (and this decision is
clearly theirs) would entertain such a fundamental change to the way they
work, the case that a problem exists would have to be made far more strongly
than what I see here. There needs to be some tangible, measurable pain being
experienced by both the user community and the commercial ecosystem to
expect the committers to buy in to such a sweeping change.

"Ed Burnette" <ed.burnette@sas.com> wrote in message
news:dbsfl5$8jj$1@news.eclipse.org...
> Ok, even if I'm wrong about the time & stress level argument, that was
> really the weakest one. How about the other reasons I sited, especially
> the first two?
>
> 1. Users only downloading release versions (and implications that has),
> 2. Yearly not the norm for OSS projects (this is hurting Eclipse with
> respect to certain other projects), and
> 3. Quality (due to more timely feedback and 'tenting').
>
> Ed Merks wrote:
>> From my personal experience, much of the 'end game' overhead is fixed
>> because rather than being proportional to how much new work has been
>> done, it's proportional to the total amount of function provided, all of
>> which needs (re)testing. My feeling is that more releases will increase
>> the burden, stress, and overhead, and will make it harder to tackle
>> larger issues. This idea gets a definite -1 from me...
Re: More frequent releases needed [message #22180 is a reply to message #21869] Tue, 26 July 2005 18:08 Go to previous messageGo to next message
Mike Milinkovich is currently offline Mike Milinkovich
Messages: 258
Registered: July 2009
Senior Member
I am a -1 on this for the following reasons:

1. We already have *lots* of users downloading milestone builds and giving
feedback on the progress. I can promise you that we see the spikes in
download numbers whenever a milestone is shipped. Yes, the majority of
users only download the release versions, but given the volume and quality
of the feedback the community provides based on the milestone builds, I do
not perceive a problem. Can you be clearer in the issue you have with the
status quo on this item?

2. I am personally not aware of any OSS project relationships with which our
schedules are impacting the Eclipse community. Can you provide some concrete
examples?

3. Eclipse already has a high level of quality. And although this may be a
question of semantics, I feel that the Platform project already does follow
the key elements of agile development. They test and test often, as can be
seen by the general stability of the milestone builds. So the assertion that
increasing the number of release cycles would improve quality is pure
conjecture IMHO.

4. (....and this is the clincher in my view.) Eclipse has a large and
rapidly growing ecosystem of products and open source projects which depend
upon Eclipse. Certainly in the case of product developers, IMHO the majority
are not going to see any advantage of being pressured to ship more often
than they currently are. Commercial developers value predictability and a
key value that the current process gives them is the calming assurance that
Eclipse will hit its dates and that they can reliably build their plans
based on that assumption. Perturbing our working system as you have
described would add increased workload and risk to many downstream
organizations which build upon the Eclipse platform.

In my view it is the committer community that controls the schedules and
this is ultimately their call. Not the users. Not the Foundation. The
committers. And frankly I believe that you would have to make a much
stronger case that there is measurable and tangible pain in the user and
plug-in developer communities before you will get the necessary buy-in from
the committers and the project leaders.

In other words, if it ain't broke, don't fix it :-).


"Ed Burnette" <ed.burnette@sas.com> wrote in message
news:dbsfl5$8jj$1@news.eclipse.org...
> Ok, even if I'm wrong about the time & stress level argument, that was
> really the weakest one. How about the other reasons I sited, especially
> the first two?
>
> 1. Users only downloading release versions (and implications that has),
> 2. Yearly not the norm for OSS projects (this is hurting Eclipse with
> respect to certain other projects), and
> 3. Quality (due to more timely feedback and 'tenting').
>
> Ed Merks wrote:
>> From my personal experience, much of the 'end game' overhead is fixed
>> because rather than being proportional to how much new work has been
>> done, it's proportional to the total amount of function provided, all of
>> which needs (re)testing. My feeling is that more releases will increase
>> the burden, stress, and overhead, and will make it harder to tackle
>> larger issues. This idea gets a definite -1 from me...
Re: More frequent releases needed [message #22224 is a reply to message #22093] Wed, 27 July 2005 11:15 Go to previous message
Eclipse User
Originally posted by: eclipse3.rizzoweb.com

Mike Milinkovich wrote:
> I would expect that before the committer community (and this decision is
> clearly theirs) would entertain such a fundamental change to the way they
> work, the case that a problem exists would have to be made far more strongly
> than what I see here. There needs to be some tangible, measurable pain being
> experienced by both the user community and the commercial ecosystem to
> expect the committers to buy in to such a sweeping change.

The "pain" I think is that the distance between releases is very large.
Take, for example, the time it took for us to be able to say "Yes,
Eclipse fully supports JDK 1.5" without having to qualify it with "...in
the pre-release builds."
There are other examples, but that is a big one that sticks out in
recent history. See, the JDK support was well underway LONG before 3.1
was ready for release, even before Sun had officially released the JDK.
Eclipse was not behind the game, but it appeared to be to many outsiders.

Anyway, please don't pick on that one example in isolation. The greater
point is that there is a "pain" and it is that we have to wait a year
between releases. That was the whole point of bringing this up in the
first place, I think. I might be worthwhile to try a shorter release
cycle for a couple of releases - after all, in agile development you
must continuously refactor; that does not only apply to code and design
but also to process.

Thanks for listening,
Eric
Previous Topic:Any Committer Members?
Next Topic:Sun is bashing Eclipse contributors!
Goto Forum:
  


Current Time: Tue Sep 02 07:59:46 EDT 2014

Powered by FUDForum. Page generated in 0.02090 seconds