[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipse-pmc] post 3.4.2 builds
|
Good points.
Re #0, "completely untested" feels like a bit of an
overstatement. One advantage of doing a full build is that we can get a
full automated test pass. That's more testing than what we get if you or I
just rebuild our plugin and put it up on a web page
somewhere.
Re #1, yes, that's the tradeoff and it's hard to say which
is right. As an example, MSFT releases their hotfixes as individual
patches, individually installable and uninstallable; I assume that's because of
customer pressure. So indeed maybe having a single update site is not the
right thing.
Re #2, I think this is already the situation.
Third-party products are already based on post-..2 releases (I know IBM does
this, and BEA did too). Even between service releases people patch
specific plugins. Product name and release train has never been a reliable
indicator of plug-in version.
I do think the releng resources are a very significant
issue though, not to be glossed over. On the other hand, if we don't do it
as an automated joint build, someone's gonna have to teach me how to sign
packages and make an update site, and that might be even harder
:-)
Thanks,
-walter
For me, the build would
contain fixes that product teams from different companies and different
developers felt were needed for a 3.4.3 build (if there was one, but there
wasn't). It would be totally untested. That's bad but we could say
this up front.
1) Consumers of the
build would need to be ok with this and I suspect that they would not.
For example, you care about one small bug in JDT but you risk a bunch of
unrelated code from SWT that could break your product completely.
2) What people were running in the field
would depend on when the build was made. How could bugs be reported
against it or when something breaks, how can we know what the person is
actually running?
