[platform-update-dev] Enhancement to update for development builds

[Rich Kulp <richkulp@xxxxxxxxxx>]

Hi,

I opened 

https://bugs.eclipse.org/bugs/show_bug.cgi?id=77143

as a suggestion for an enhancement.
It was asked that I open the discussion here for everyone's thoughts and
suggestions. Here is a copy of the discussion so far:

Title: Allow development drivers thru
update manager


EMF produces development drivers on their update site.
A lot of people like
this, being able to use the update manager for builds too. We would like
to
start doing this for VE also.

But the problem is the version naming that needs to be used. For example,
if
they are developing for version 2.0.2, then the versions of the plugins/features
during development are named 2.0.2.I20041001 to indicate the build id of
it. 

The problem occurs when they publish the final released 2.0.2. The problem
is
that to the update manager it thinks 2.0.2 is downlevel from 2.0.2.I20041001
and
so it won't allow an update. The user must physically remove it from the
configuration by hand, do a -clean, and then apply the final 2.0.2 update.

My suggestion is allow a convention like:

  2.0.2.dev_I20041001 

to indicate this is a development version of 2.0.2, so that 2.0.2 will
be
considered to be up-level from the development version. The update manager
would
need to be changed to see the dev_ as being downlevel.

And if you are trying to do 2.0.2.1, then use 2.0.2.1_dev_I20041001 to
indicate
this is a development driver of 2.0.2.1 and so 2.0.2.1 will be considered
to be
up-level from 2.0.2.1_dev_I20041001. Here the _dev_ would be considered
downlevel.

However, within the dev, the rest of it would still apply. In other words,
dev_I20041006 would be considered uplevel from dev_I20041004 (using the
same
string sort order used now on the fourth part of the version).

Thanks.

------- Additional Comment #1
From Dorian
Birsan 2004-10-27 19:44 ------- 
Rich, would the milestone builds be numbered as
2.0.2.M3 or something similar?
Just going by I builds may not be what the community wants, as many people
prefer to pick up stable builds.
In this case, it would be problematic to update from M1 to I build that
follows, unless we modify your proposed scheme.

I suggest you propose these changes on eclipse-dev and/or platform-update-dev
so others have some input before getting down to implementing it (the 
implementation should be relatively straightforward).

Thanks for your input,
Rich Kulp