RE: [eclipse-dev] Talking of version

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

<warning type="tongue in cheek">
Following this approach we could actualy
just get rid of version numbers and stamp plugins with build timestamps.
If they are all 3.0.0.T then the 3.0.0 is redundant.  This would make
things in the runtime *much* simpler.
</warning>

Numbering the plugins appropriately
does not mean that the feature or downloads numbering has to change.  Those
are just packagings of the plugins.  I've not thought far enough to
see if having the features numbered 3.0.0.T would be good/bad/indifferent.

The scenario you describe appears random
but it is not really if the version numbers actually had semantics.  If
I put the shoe on the other foot, I currently have no way measuring compatibility
between org.eclipse.core.resources 2.1 and 3.0.  On the surface they
are incompatible.  In reality they are highly compatible.  

I think the problem is real.  So
real in fact that simply telling everyone to use the same number will not
solve it.  We need higher level abstractions and structures, not numbering
conventions.  I don't have the answer but think that if we cannot
solve it using the technology in Eclipse (e.g., meaningful version numbers
and update manager) then we should fix Eclipse.  That is, if we cannot
manage to do it, how do we expect others to do it?

Jeff

"Ed Burnette" <Ed.Burnette@xxxxxxx>
Sent by: eclipse-dev-admin@xxxxxxxxxxx

02/12/2004 09:53 PM

Please respond to
eclipse-dev

To	<eclipse-dev@xxxxxxxxxxx>
cc
Subject	RE: [eclipse-dev] Talking of version

I'd argue that all the version numbers should ideally
be the same across all Eclipse projects (not just Platform) for a given
build, and there should be a build number at the end, for example 3.0.0.200402101600.
Advantages:

- it allows a user to easily look at the plugins and features directories
or the About box and tell if anything is out of place
- it allows the update manager to update M, N and I builds (there should
be one update server for production, one for M, one for I, and optionally
one for N).

I know some subprojects are on "Platform time" for builds and
some are not. I'd argue that the ones that are not should move over to
it whenever it's feasible for them to do so. Especially ones like EMF and
GEF which are prerequisites for other tools. This will make it much easier
for everybody who has to mix and match components to figure out what goes
with what.

Developers who are only using the Platform don't understand what a pain
this is. Imagine if SWT, Ant, Platform Core, Platform UI, JDT, and PDE
were all numbered differently and were all built on a random schedule.
Say Ant 1.6 required Platform Core 2.5.1 or higher, and Platform UI 2.4
required SWT 3034. PDE 1.5 requires Platform UI 2.1.3 but there's a 1.6
that requires Platform UI 2.5 (available from some integration build).
You'd drive yourself nuts trying to make it all work together. Now imagine
the poor user trying to put together 19 different projects from the download
pages - that's how many there are today, with maybe double that in a year
or two.

-----Original Message-----
From: Jeff McAffer [mailto:Jeff_McAffer@xxxxxxxxxx] 
Sent: Thursday, February 12, 2004 2:10 PM
To: eclipse-dev@xxxxxxxxxxx
Subject: Re: [eclipse-dev] Talking of version

I think you and Pascal are effectively saying the same thing.  The
issue we have right now is we inc'd all our version numbers to 3.0.0 from
2.1.x.  According to our advertised versioning semantics, this means
the new code is not compatible with 2.1.x.  As the development team
is brutally aware, we are in fact largely binary compatible with 2.1.  Some
plugins did not change at all!  The fact that we inc'd the version
numbers this way is itself a breaking change! 
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
http://dev.eclipse.org/mailman/listinfo/eclipse-dev