Hi!
let me start by saying that I feel proud about the
rigor with which ASF approaches management
of the ultimate foundation deliverables: the source
releases put out by our communities. If you read our
policy document:
http://www.apache.org/dev/release.html
and only focus on the source releases it is obvious
to me that we strike a great balance between fostering
innovation while practicing strict IP hygiene.
Unfortunately, I can't really say the same for the parts
of the policy that covers binary convenience artifacts.
The way our policy talks about these artifacts seems to
invite different interpretations which is especially
problematic for training podlings in the "Apache Way"
(hence even though this discussion is perfectly applicable
to TLPs I'm starting it here on general@incubator).
The biggest source of confusion that I personally witnessed
comes from interpreting 'general public' vs. 'developers'.
The problem there seems to come from the false assumption
that our projects always have a user base that is non-developer
in nature. For projects like libraries or frameworks this is simply
not the case. The end-users of such projects are always, by
definition, developers.
Think of them as downstream developers integrating with ASF
projects via binary artifacts. These folks always embed ASF
project into larger systems. They also, typically, live and die
by the level of API compatibility that the upstream ASF-produced
dependencies maintain. This, in turn, puts pressure on ASF
upstream projects to maintain a healthy and convenient channel
for managing non-release, downstream integration binary artifacts.
Unfortunately, our current release policy is extremely confusing when
it comes to this very important use case. What's worse, in my opinion
it gets in the way of fostering user community for projects where
users == downstream developers.
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."
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'? I've always assumed that we are not and the way
policy is currently worded is just sloppy.
I know that there's been a number of threads over the years that tilted
at the windmill of clarifying our policies around binary releases. At this
point, I'm actually taking a step back and asking a bigger question: why
don't we take a more nuanced approach towards the very issue of
what makes a release a release.
IOW, I would like to focus on answering the question of how can we
empower our communities to effectively communicate *their* intent
of how *they* expect an artifact to be consumed.
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.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
