There is nothing preventing "clearly identifiable non-release artifacts available to the general public". Many projects make automated nightly builds available for example.
Sent from my Windows Phone ________________________________ From: Roman Shaposhnik<mailto:ro...@shaposhnik.org> Sent: 6/23/2015 12:23 PM To: general@incubator.apache.org<mailto:general@incubator.apache.org> Subject: Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts On Mon, Jun 22, 2015 at 10:16 PM, Marvin Humphrey <mar...@rectangular.com> wrote: > The distinction is between people who develop the Apache product, and > those who use the Apache product. Well, that's part of the reason behind me starting this thread: I think it is time for us to explicitly acknowledge a third role: an downstream project developer integrating with Apache *project*. I believe we have enough evidence that this group of people has unique requirements. >> How am I supposed to invite all the downstream developers of the >> world to start integrating with my awesome feature FOO before it >> gets formally released when our policy makes statement like: >> "If the general public is being instructed to download a package, >> then that package has been released." > > Rather than invite them in before you make a release, why not release > first and then invite them in? Because I want their feedback during the release cycle, not after. IOW, I need them to download and integrate with half-baked functionality that I may be not comfortable putting into a release. >> Are we really suggesting that I can not present at conference, tweet >> and otherwise promote the awesomeness of my project based on >> 'what's coming'? > > Why not release before presenting, tweeting, or promoting? See above. >> After all, we have a really good way of communicating that type of intent >> when it comes to branding: if you want to communicate that Apache >> FOO is a poddling you MUST refer to it as Apache FOO (incubating). >> Simple and effective. Exact opposite of our release policy that seems >> to completely discount labeling for communicating intent. I'm sorry, >> but a -SNAPSHOT labeling of a version ID communicates as much >> (if not more) to me as a writing on a website does. Lets just recognize >> that. > > If artifacts are being consumed by people other than those who develop > the Apache product, those artifacts need to be vetted and voted. Like I said -- I'm 100% with you when it come to source artifacts. Can somebody please explain to me what is a the danger to the foundation is a [P]PMC wants to make a clearly identifiable non-release artifacts available to the general public? Thanks, Roman. --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
