Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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


Back to the top