Re: [epp-dev] Role, importance, or use of pre-req feature versions?

[David M Williams <david_williams@xxxxxxxxxx>]

I'm glad I asked, since made me more confused :) 

Let me see if I am understanding; if we specify, in our feature.xml, 

   <requires>
      <import feature="org.eclipse.cvs" version="1.1.0" match="compatible"
/>

Then "cowboy" users would not be able to update to org.eclipse.cvs version 
1.2? (even if the plugin level constraints were still satisfied). 

I believe our main audience, by the way, at least for JEE IDE, is not the 
cowboy user, but more the casual, beginning user. I would not mind 
"protecting them from themselves" if possible, but to not allow any new 
features sounds a little too protective. 







From:
Eric Rizzo <eclipse-mail@xxxxxxxxxxxx>
To:
Eclipse Packaging Project <epp-dev@xxxxxxxxxxx>
Date:
05/16/2009 01:37 PM
Subject:
Re: [epp-dev] Role, importance, or use of pre-req feature versions?
Sent by:
epp-dev-bounces@xxxxxxxxxxx



+1, I agree wholeheartedly with Thomas.
As Bjorn so controversially wrote, Eclipse is not truly a product 
provider; I think making the packages more like products (as Pascal has 
described them) will violate the principle of least surprise for users 
(especially while most users don't even know about the Eclipse Project 
builds as the alternative).
I disagreed with Bjorn's idea of stopping distributing the binaries from 
eclipse.org, but I think the "cowboy" approach is a good middle-ground. 
Besides, that is most close to how the previous releases have been, right?

Eric


Thomas Hallgren wrote:
> Pascal Rapicault wrote:
>>
>> So are we "products" or "cowboys"?
>> Personally, I would vote for the EPP packages to be "products" because 
>> I believe that our audience expect "products" despite the careful 
>> wording put around each release.
>> What are you?
>>
> IMO, we're "cowboys". I would be very annoyed if I were unable to update 

> the features of my package. Especially given that it contains a 
> state-of-the-art tool designed to do just that.
> 
> The packages are deliveries from an open source community. No support 
> contracts exists and the end user is using our software at no cost and 
> at his own risk. He knows that and he has learned to like it because the 

> release cycles are shorter and the support from the community is much 
> better then he can ever hope for from huge companies like Oracle or IBM 
> (even though he pays them handsomely). The short cycles is advantageous 
> to the producer too since he gets much quicker feedback (positive and 
> negative) on new versions and can act accordingly.
> 
> The "cowboy" approach helps keeping a viable and vibrant community 
> around the software. A "product" approach is really devastating in that 
> respect and would antagonize a majority of our users.
> 
> If some companies would like to capitalize on the fact that we don't 
> provide "products" with support contracts, well let them. I bet some 
> people would be willing to pay for slow release cycles and having the 
> updates disabled as long as it is combined with a support contract. The 
> Eclipse community however, will never provide such contracts and we 
> don't need to suffer from the inflexibility that they bring.
> 
>  From a project lead perspective, I much rather have the increased 
> debugging difficulties that you mention than cripple my community's easy 

> access to the bugfixes that I know I already published to our update 
site.
> 
> Just my 2c,
> 
> Thomas Hallgren
> _______________________________________________
> epp-dev mailing list
> epp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/epp-dev

_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epp-dev