Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipse-pmc] post 3.4.2 builds

In today's architecture call it was suggested that we consider doing
post-3.4.2 builds of the 3.4 tree.  

The sense of the meeting, I think, was that this would benefit our
customers (e.g., a central point for customers to get signed packages
when there are bug fixes needed for an Eclipse-based product); but that
there were obvious challenges in terms of messaging and releng
resources. 

The suggestion wasn't mine, but I would benefit from something like
this.  JDT-APT introduced a regression in the very last bug fix we made
for 3.4.2 - one of these deals where, in fixing one bug, we introduced a
different one, that wasn't discovered until a user upgraded.  Olivier
and I both carefully reviewed the change before it was committed, and
while in retrospect I feel awful about it and we could have been even
more conservative than we were, frankly this stuff does happen.  

The user in this case is a solution provider whose solution is now
busted by this frickin' little corner case that we'd never realized
existed, and he's politely wondering whether he needs to host a
post-3.4.2 patch update site on his web site or whether it should be on
Eclipse.  I think the answer is probably "Eclipse" because someone else
will inevitably hit this and I want to have an answer for them.

My default idea is to create an update site for the plug-in in question,
dangling off the Eclipse JDT-APT web page.  But that seems slightly
silly if there are also going to be fixes over time in other components,
as there have been in 3.2 and 3.3.  Imagine the poor user who needs to
get a collection of these fixes.  I'd much rather point them to a single
place, even with the understanding that it is not for everyone and that
the fixes there are "caveat updator."

So, my straw-man proposal would be:

1. We do periodic post 3.4.2 builds - say, once every month or two.
2. These get an automated test run but no performance tests or manual
integration testing (no test day).
3. They are made available from a single update site hosted on
eclipse.org.
4. Information about that update site states that the code has not been
fully tested and that users should only update if they are encountering
a specific bug that is known to be fixed in the update.


There are plenty of holes in that proposal, but maybe it's at least a
starting point for discussion.

Thanks,
  -walter



Back to the top