| Re: [epp-dev] Role, importance, or use of pre-req feature versions? |
> 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).
Cowboys users *would be able to* update to a new version of CVS (granted that all the other dependencies are met).
> 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,
This is what I thought too. Leaving the ability for people to run untested set of stuffs is not, IMO, the best way to promote our hard work.
> but to not allow any new features sounds a little too protective.
Users will still be allowed to install new features from any repo (granted all the dependencies of the software to install are satisfiable). The only thing that will not be authorized is replacing the features that are strictly included in the Package.
Even though I think it would be good to come to a common "rule" for all the EPP packages, I don't know if this will be possible. For me, the point of the discussion is to have every package maintainer think about the implication of the way they are building their package, and it may be be fine for each package maintainer to decide for themselves what it is they want to do.
>
>
>
>
>
>
>
> 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
>
>
>
> _______________________________________________
> epp-dev mailing list
> epp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/epp-dev