| Re: [cross-project-issues-dev] Some observations on Callisto Fall Maintenance |
> I agree with Pascal's exclamation regarding the 3 new plugins. I have trouble understanding how that could possibly be justified in a maintenance release Let me try then, since one of these was added by DTP...... In our case, we have a SQL parser component that uses a third party library called "lpg.jar". Between Callisto June and Callisto September, the original download location for this jar became unavailable (we don't have approval to redistribute the jar yet, so we ask users to download this item separately) and a new location was created on SourceForge. Migrating to this new location required some minor refactoring for package names and, in light of the move to centralize third party jars in a "commons" project, we felt it would be a good intermediate step to create a wrapper plug-in for this, and point the parser plug-ins at it, rather than embedded the jar in two of the parser components as done previously. (Once the commons project contains a shared version of this library, we'll move to that and remove the wrapper from DTP.) In the end, this new wrapper plug-in adds no new functionality, but merely remaps internal DTP dependencies. It also responds to external changes in library availability. I understand the arguments for "bug fix" only maintenance releases, but I also believe that one of the strengths of Eclipse is the distribution/delegation of responsibility among projects within certain well-defined policies. Regards, John Graham Eclipse Data Tools Platform PMC Chair Staff Software Engineer, Sybase, Inc. http://dataplat.blogspot.com/ Steven Wasleski <wasleski@xxxxxx. com> To Sent by: Cross project issues cross-project-iss <cross-project-issues-dev@eclipse.o ues-dev-bounces@e rg> clipse.org cc Subject 09/28/2006 11:29 Re: [cross-project-issues-dev] Some PM observations on Callisto Fall Maintenance Please respond to Cross project issues <cross-project-is sues-dev@eclipse. org> David, First, let me say that I totally agree that this release represents a great job on a difficult task. You make an interesting proposal about qualifiers. The guidelines state the UM honors qualifier changes to better facilitate the use of UM during development so I don't think a binary change could be made to the rule. However, the addition of an option to honor qualifier differences (the default) or not (your proposal) could be interesting. With regard to api additions in a maintenance release, I generally fall in the "don't ever do it camp" (with very rare well considered exceptions). Adding api is more dangerous than people often appreciate. For example, the addition of a method to a class that is intended to be subclassed as part of the api usage can break clients, both the subclass and users of the subclass. And yes, I meant class and not interface. I think everyone understands that adding methods signatures to interfaces that are intended to be implemented by clients is just plain wrong. As for the projects where the version numbers are identical, that is certainly suspicious. However, I temper this and the observations about other suspicious version numbers with the recognition that these rules are new to many. This is just the second release (Callisto and this maintenance release) that many of these teams are trying to converge on this one set of rules along with every thing else that is going on. It is going to take a few tries to get this consistently optimized across all the projects. Finally, I agree with Pascal's exclamation regarding the 3 new plugins. I have trouble understanding how that could possibly be justified in a maintenance release. Thanks, Steve Wasleski (Embedded image moved to file: pic21577.gif)Inactive hide details for David M Williams/Raleigh/IBM@IBMUSDavid M Williams/Raleigh/IBM@IBMUS David M Williams/Rale igh/IBM@IBMUS (Embedded image moved to file: Sent by: pic09789.gif) cross-project To -issues-dev-b (Embedded image moved ounces@eclips to file: pic25605.gif) e.org Cross project issues <cross-project-issues-d ev@xxxxxxxxxxx> 09/28/2006 (Embedded image moved to file: 06:59 PM pic30195.gif) cc (Embedded image moved Please respond to to file: pic27594.gif) Cross project issues (Embedded image moved to file: <cross-project-issues-dev@xxxxxxxxxx pic07950.gif) g> Subject (Embedded image moved to file: pic16343.gif) Re: [cross-project-issues-d ev] Some observations on Callisto Fall Maintenance (Embedded image moved to file: pic00754.gif) (Embedded image moved to file: pic02481.gif) 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-bounce To s@xxxxxxxxxxx Cross project issues <cross-project-issues-dev@ec lipse.org> 09/28/2006 04:46 PM cc (Embedded image moved to file: pic01012.gif) Subject Please respond to Re: Cross project issues [cross-project-issues-dev] <cross-project-issues-dev@ecli Some observations on pse.org> Callisto Fall Maintenance (Embedded image moved to file: pic11672.gif) (Embedded image moved to file: pic23439.gif) 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-bounce To s@xxxxxxxxxxx cross-project-issues-dev@ecl ipse.org cc 28/09/2006 04:14 PM (Embedded image moved to file: pic13428.gif) Subject [cross-project-issues-dev] Please respond to Some observations on Cross project issues Callisto Fall Maintenance <cross-project-issues-dev@ecli pse.org> (Embedded image moved to file: pic05912.gif) (Embedded image moved to file: pic09762.gif) 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 _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Attachment:
pic21577.gif
Description: GIF image
Attachment:
pic09789.gif
Description: GIF image
Attachment:
pic25605.gif
Description: GIF image
Attachment:
pic30195.gif
Description: GIF image
Attachment:
pic27594.gif
Description: GIF image
Attachment:
pic07950.gif
Description: GIF image
Attachment:
pic16343.gif
Description: GIF image
Attachment:
pic00754.gif
Description: GIF image
Attachment:
pic02481.gif
Description: GIF image
Attachment:
pic01012.gif
Description: GIF image
Attachment:
pic11672.gif
Description: GIF image
Attachment:
pic23439.gif
Description: GIF image
Attachment:
pic13428.gif
Description: GIF image
Attachment:
pic05912.gif
Description: GIF image
Attachment:
pic09762.gif
Description: GIF image
