[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [platform-update-dev] Investigating some alternative update manager
- From: Peter Manahan <manahan@xxxxxxxxxx>
- Date: Mon, 6 Nov 2006 18:53:22 -0500
- Delivered-to: email@example.com
All the problems below that Ed mentions are some of
the reasons we moved away from update manager as an install/update/deployment
mechanism for our eclipse IDE based products (RAD,RSA etc). Support "non-osgi/eclipse"
content in a first class way and the removing the line between initial
installation and update is key for future work imo. Most applications contain
a variety of content databases, windows com dll's etc. Some also contain
multiple eclipse or other runtimes which all need to be installed/updated
The end user is the most important person in this
story and unlike eclipse ide itself the end user in many cases of install/update
is not a developer at all, even if they are installing eclipse ide. Just
something to keep in mind while thinking about this.
platform-update-dev-bounces@xxxxxxxxxxx wrote on 09/14/2006
> IMHO the biggest problem with the update manager today is it can't
> update everything. Just the other day I was trying to help a co-
> worker who reported that a plug-in I wrote wasn't working. It turned
> out she was running Eclipse 3.0 and the plug-in required 3.1 or 3.2.
> She had no idea she was running a back-level version of Eclipse.
> "I've always run the update manager", she said, "and
I assumed it
> would update me". I told her she had to install a whole new version
> of Eclipse so she did, and of course she unpacked it right on top
> the old version before I could stop her. So I had her redo it in a
> clean directory, but then she lost all the add-ins she had collected
> (like CodePro) and had to reinstall those. This kind of thing
> happens all the time. I know exactly why it works this way but it's
> very user un-friendly.
> The second biggest problem with the update manager today is it
> doesn't deal with different versions of plug-ins that are targetted
> to different versions of Eclipse. Case in point. We have an internal
> update site for plug-ins that employees have written. Recently
> someone wanted to upgrade an older plug-in to take advantage of a
> new feature in Eclipse 3.2. However they couldn't because users are
> running various versions of the Eclipse SDK including 3.0, 3.1, 3.2,
> or 3.3. And there's also the case of new Eclipse versions breaking
> old plug-ins that rely on internals (you know you write them). The
> manual work-around of having a different URL for each version of the
> SDK (updates/30, updates/31, etc.) is a pain to maintain and get
> everyone to use it consistently and doesn't scale. There should be
> better way.
> I wish I could help solve these problems with a code contribution
> but all I have time for right now is to complain about it and point
> to auto-updating programs like Firefox that seem to have solved it
> already. So if these kinds of issues can be addressed with "Update
> manager - TNG", that would be great.
> platform-update-dev mailing list
Description: S/MIME Cryptographic Signature