Re: [cross-project-issues-dev] Some observations on Callisto Fall Mainte

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

It sounds like the root of the problem
is that the versioning guidelines make certain assumptions about development
practice that stem from the policies of the platform project.  For
example, it is assumed that "non essential" changes are never
made in a maintenance release, since stability of code and minimizing the
testing burden are considered paramount.  Only serious bugs and internalization
issues are addressed, only when considered "essential", and all
therefore warranting an increase in the service segment.  Likewise,
the platform project has a policy of never adding API (or new plugins)
in a maintenance release.

Clearly other projects have different
development practices, and rightly so.  Projects in earlier stages
of maturity are more likely to need to tweak their API, for example.  Also,
some projects put more emphasis on avoiding the pain of development across
several streams than on stability of the maintenance branch (I.e., avoiding
forking a plugin into multiple branches until necessary, causing more non-essential
changes to appear in the maintenance branch).

I think we should use this experience
to evolve the versioning guidelines to accommodate the development practices
of the other projects in the Callisto/Europa group. It is certainly not
the place of the versioning guidelines to mandate these kind of development
practices across projects - that's the job of the project PMCs.  Since
version numbers are a common currency that span projects when plugin dependencies
cross project boundaries, they need to account for the realities of how
different projects operate.

John

David M Williams <david_williams@xxxxxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

28/09/2006 06:59 PM

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

To	Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
cc
Subject	Re: [cross-project-issues-dev] Some observations on Callisto Fall        Maintenance

Just to clarify a little, I think you mean that is 66 that  _might_
 be in error, right?  Emphasis on the 'might be'? 

I know in WTP, we looked pretty closely at those where only the qualifier
increased, and in all cases is was a "non essential" change,
for example, maybe corrected a spelling mistake or even perhaps changed
the warning level in some 'settings' file (so, touched in cvs, but made
no real difference).  The thought was, if someone was installing anew
or loading from cvs, why not give them the right version, but if someone
already had the old one installed, there was no reason to _require_ a new
version be installed for those cases. That seems correct to me, even if
update manager does not currently support it. That is, I believe UM always
installs the qualifier increased version, even though considered, by design,
to be nonessential. 

As for the minor updates, while "dangerous" to do in a maintenance
release (e.g. for NL fragment coordination!), we thought as long as well
communicated, it was still the correct thing to do if a new API _had_ to
be added, since clients could then choose to specify that minor version
as their minimum requirement, if they infact depended on that API. If you
are saying new API can never be included in a service release, that new
API could only be introduced once per year, well ... then, maybe that is
a restriction that should be addressed!?  I know in the rdb.core case,
it was for a new extension point, that some clients really needed, but
wouldn't break anyone currently using the old one. So, maybe I don't understand,
but still seems correct to me. 

I might also add that some of the 400 that showed a increase in service
level _might_ be in error too. That would be the "beta error"
that implies a change, when there really was none. I only suggest this
because some project's version numbers are all suspiciously identical with
each other ... maybe an error, maybe not.  You have to trust the provider.

I still think a great job on a difficult task ... and, if anything, these
persistent issues just highlights the need for better build tools and version
evolution tools ... and, as always, the welcome discussions here on 'cross
projects'.

John Arthorne <John_Arthorne@xxxxxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

09/28/2006 04:46 PM

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

To	Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
cc
Subject	Re: [cross-project-issues-dev] Some observations on Callisto Fall        Maintenance

150 no change 
60 qualifier only increased 
400 service version increased 
6 minor version increased 
3 new plugins 

Sigh... According to these version numbering guidelines, that's at least
66 mistakes in plugin versioning: 

http://wiki.eclipse.org/index.php/Version_Numbering

I have no idea whether all Callisto projects were intending to follow these
guidelines, but I'll just say that if you are intending to follow them,
they don't account for plugins that change only their qualifier across
releases, or change their minor version (new API) in a maintenance release.
 The system just breaks down... plugins that depend on these 66 plugins
won't have any way to accurately describe their dependencies.

John

David M Williams <david_williams@xxxxxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

28/09/2006 04:14 PM

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

To	cross-project-issues-dev@xxxxxxxxxxx
cc
Subject	[cross-project-issues-dev] Some observations on Callisto Fall        Maintenance

For those who like numbers, just thought I'd relate these. 

All of the "visible" features from callisto update site incremented,
except for about 5, which were all "3rd party" features. 
So ... either lots fixed, or, teams aren't following the versioning rules
:) 

But I do think a lot fixed! Here's some rough numbers, based on the links
in 
http://wiki.eclipse.org/index.php/Callisto_Coordinated_Maintenance#What.2C_exactly.2C_is_fixed.3F

Bugs fixed 

WTP      686 
Eclipse  396 
Birt     763 
TPTP     232 
DTP       23 
GMF      261 
VE         7 
EMF       65 
EMFT       ? 
GEF        2 

Total   2435 


Here's my assessment of what changed at the plugin level: 

150 no change 
60 qualifier only increased 
400 service version increased 
6 minor version increased 
3 new plugins 

619 Total Plugins 


Those 150 unchanged plugins must be small ones, since installing Callisto
maintenance on top 
of existing Callisto was only 15 Megs smaller than just re-installing the
whole thing. 

Approximate Megs used to install all of Callisto from Update site

200 Megs  Initial, summer version 
385 Megs  After adding Fall maintenance 

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - 

Should be interesting to compare to spring maintenance! 

And when I think of the magnitude of all these numbers, its sort of amazing
it all comes together! 
Thanks again. 


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev