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

[Rich Kulp <richkulp@xxxxxxxxxx>]

This has just been added with some good
info to the bug:

Any thoughts?

------- Additional Comments From pascal_rapicault@xxxxxxxxxx
 2004-10-28 11:51 -------
I see two problems to this approach:
- it puts semantics on a number something that does not have one.
- it forces a renumbering or rebuild of the plugins when we are ready to
ship.

The first one is unfortunate because we already ship plugins that makes
use of 
the 4th segment and that we do not necessarily control the version scheme
(for 
example lucene), the second approach has already been tried and refuted
in the 
past because it puts extra burden when we are about to ship, many files
may 
need to be updated (plugins, features, ini files) introducing potential
perturbations. Another problem is that you tag as 2.0.2 because you are
sure it 
is the last version, but then you see a last bug that must be fixed...
how do 
you handle that? 

A few months ago we proposed the usage of meaningfull version numbers (see
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core-
home/documents/plugin-versioning.html) but it's been rejected because with
the 
argument that we want to show people a nice version number like 3.0.0 instead
of 3.0.0.3.

Since then I thought that a solution could consists in adding an extra
field in 
the features and plugins called buildId. This buildId would be free form
and 
would mainly be used by update to support upgrade from 3.0.1 build I2004
to 
3.0.1 build I2005. In this case the build id would not take precedence
over the 
version id.


Thanks,
Rich