On Wed, Nov 27, 2019 at 1:04 PM Elliotte Rusty Harold <[email protected]> wrote:
> On Wed, Nov 27, 2019 at 1:12 PM Kenneth Knowles <[email protected]> wrote: > > > > > *Opt-in*: This is a powerful idea that I think changes everything. > > - for an experimental new IO, a separate artifact; this way we can > also see downloads > > - for experimental code fragments, add checkState that the relevant > experiment is turned on via flags > > To be clear the experimental artifact would have the same group ID and > artifact ID but a different version than the non-experimental > artifacts? E.g. > org.apache.beam:beam-runners-gcp-gcemd:2.4.0-experimental > > That could work. Changing the artifact ID or the package name would > risk split package issues and diamond dependency problems. We'd still > need to be careful about mixing experimental and non-experimental > artifacts. > That's clever! I think using the classifier might be better than a modified version number, e.g. org.apache.beam:beam-io-mydb:2.4.0:experimental My prior idea was much less clever: for any version 2.X there would either be beam-io-mydb-experimental or beam-io-mydb (after graduation) so no problem with a split package. There would be no "same artifact id" concern. Your idea would allow us to ship two variants of the library, if we developed the tooling for it. I think doing the stripping of experimental bits and ensuring they both compile might be tricky unless we are stripping rather disjoint piece of the library. Kenn
