RE: [eclipse-dev] Talking of version

[Scott Fairbrother <scottf@xxxxxxxxxx>]

I'm of the opinion that the Eclipse
installation/configuration component is an isolated attempt to solve one
aspect of application life cycle management. Installation and configuration
management is a hard problem to solve, however Eclipse does not embrace
or exploit an industry standard solutions to this tough problem.  Just
as the platform runtime evolved to OSGi, it's time that Eclipse looks at
the bigger picture of the application life cycle and embrace the interoperability
of management standards set forth by the Distributed Management Task Force
(DMTF).  Reference the open source Java Web Based Enterprise Management,
WBEM Services project at sourceforge: http://wbemservices.sourceforge.net/

The Common Information Model (CIM) specifications
desribe the entire business entities, hardware, software, network, users
& security etc. The domain includes the entire enterprise and on the
internet.  The model includes an Application Management sub-model
describes the details required for system management providers to manage
software products and applications throughout the application lifecycle
(cradle to grave).  The model supports installation management, configuration
management, software inventory management, and incident management applications,
to name a few.  There are multiple adopters   The model describes
an applications with various structures used to describe a single software
product as well as a group of interdependent software products that form
a business system. With regard to application life cycle state transition
to an installable condition, the Check class is used to check the following
attributes:

Requirements

Minimum Amount of memory
Disk Space 
Minimum amount of disk space
required to transition into the next
state.
Swap Space 
Minimum amount of swap space
required to transition into the next
state.
Architecture 
The architecture required by the
software element to transition into
the next
state.
Files 
A file that is expected to exist
or
not exist before a software element
transitions into the next
state.
Directories 
A directory that is expected to
exist or not exist before a software
element transitions into the next
state.
OS Version 
The version or ranges of versions
a
software element requires before
it
transitions into the next
state.
Software
Elements
A software element that is
expected to exist or not exist
before a software element
transitions into the next
state.
Setting
An entry in a "setting"
file that is
expected to exist or not exist when
a software element is in the next
state.
Version Compatibility
Indicates whether it is permissible
to create the software element in
its next state.

Thanks,
Scott Fairbrother
Eclipse/WebSphere Studio Jumpstart Team
N110/501
IBM Corp 
4205 South Miami Blvd.
RTP, NC 27709
Voice : 919-254-1488
TL : 8-444-1488

The Java Developer's Guide to Eclipse - http://www.aw.com/catalog/academic/product/1,4096,0321159640,00.html?type=PRE
WebSphere Studio - http://www.ibm.com/software/ad/adstudio
Ready for WebSphere Studio partner program - http://www.developer.ibm.com/websphere/ready.html

Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>
Sent by: eclipse-dev-admin@xxxxxxxxxxx

02/12/2004 07:37 PM

Please respond to
eclipse-dev

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

<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