Re: [cross-project-issues-dev] Fw: About the update site URL for dtp 1.7

[Kim Moir <Kim_Moir@xxxxxxxxxx>]

We have different update sites for each
release.  We use product builds so we specify the p2 sites for the
Eclipse Project and Galileo in the builder's p2.inf files for each product.
So the user sees these sites automatically.

This ensures that the user running our
3.5 build isn't trying to install old content such as Ganymede which might
not play well with 3.5 bundles.  Also, it avoids issues where the
format of the metadata changes from release to release.  Or where
an old bundle with the same version and qualifier is overwritten when it'is
built with a new compiler or pde build etc.

Looking foward, you might want to consider
implementing composite respositories.  Composite repositories ensure
that each build has its' own directory which greatly simplifies repository
management. 

See

http://wiki.eclipse.org/Equinox/p2/Ant_Tasks

http://relengofthenerds.blogspot.com/2009/02/implementing-composite-repos-in-your.html

Kim

brian.fitzpatrick@xxxxxxxxxx
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

05/26/2009 03:56 PM

Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>

To	Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
cc
Subject	[cross-project-issues-dev] Fw: About the update site URL for dtp        1.7.0

Hi all... 

We have a weird, next-to-impossible update site issue that we've been trying
to track down since our 1.6.2 (Eclipse Ganymede SR2) release went out in
February. Intermittently we're having people report issues updating to
1.6.2 and installing other projects. 

Xiaoying, who's been helping us out with our builds for the last couple
of releases, is proposing that perhaps this is due to the fact that we
have one update site for all of DTP. Some teams seem to provide separate
update sites for each release, while others don't.

The biggest concern with splitting out the DTP update site on a per-release
basis from a PMC perspective is that users would have to know which update
site to use. And if a user is updating from 3.4 to 3.5 (DTP 1.6.x to 1.7),
how do they know that they need a separate URL for the new update site?
This seems like a big risk. 

How are other projects handling the whole update site issue? And has anyone
else seen issues with mix/match update sites? 

Thanks in advance! 
--Fitz 

Brian Fitzpatrick
Eclipse Data Tools Platform PMC Chair
Eclipse Data Tools Platform Connectivity Team Lead
Staff Software Engineer, Sybase, Inc.

----- Forwarded by Brian Fitzpatrick/SYBASE on 05/26/2009 01:50 PM -----

"Xiaoying Gu" <xgu@xxxxxxxxxxx>

05/26/2009 03:15 AM

To	<brian.fitzpatrick@xxxxxxxxxx>, "Linda Chan" <LChan@xxxxxxxxxxx>
cc
Subject	About the update site URL for dtp 1.7.0

Hi All, 
  
Current, the update site URL for DTP release is http://download.eclipse.org/datatools/updates
In the past releases, we will copy the release update site jars to this
URL after release build is announced, and append the new release to the
site.xml. 
And this URL is listed as default URL once datatools is installed.
  
This will cause one issue: 
After 1.7.0 is released, Ganymede users will find datatools 1.7.0 updates
when they use software updates. So DTP 1.7.x might be mixed up with platform
3.4, BIRT 2.3, dtp 1.6.x after installation from update site. Would this
be a potential issue? 
  
  
Other teams use a separate update site for each release, like http://download.eclipse.org/eclipse/updates/3.4
and http://download.eclipse.org/eclipse/updates/3.5
Do we need to makes changes for 1.7.0 release? 
  
  
  
Thanks, 
Xiaoying 
 _______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev