Josh, I've enabled the basic integration tests in my updated patch: https://github.com/apache/calcite/runs/4513702440?check_suite_focus=true
LMK if you think that is sufficient. Thanks On Mon, Dec 13, 2021 at 4:05 PM Jacques Nadeau <jacq...@apache.org> wrote: > I added a blurb about snapshot releases in the howto in the updated PR. > LMK your thoughts. > > https://github.com/apache/calcite/pull/2641/files# > > On Mon, Dec 13, 2021 at 11:34 AM Julian Hyde <jh...@apache.org> wrote: > >> Jacques, >> >> Your 4 points are convincing. Snapshots (used in CI) will help people >> stay on the main branch, and therefore will increase engagement. >> >> It would be useful if there were some guidance in the HOWTO on using >> snapshots. (Don't release based on snapshots; snapshots may change or >> disappear without notice; snapshots are not Apache licensed; do run >> your CI against snapshots, but remember that if they fail, there are >> now TWO places to look for the failure.) >> >> Julian >> >> >> On Sun, Dec 12, 2021 at 4:11 PM Jacques Nadeau <jacq...@apache.org> >> wrote: >> > >> > Good questions, Julian. >> > >> > Some thoughts, in random order. I think snapshot releases have the >> ability >> > to: >> > >> > 1. Reduce the likelihood of long-lived forks >> > Right now, the easiest way one has to produce snapshot artifacts is to >> set >> > up a separate process around a forked repo. Once this process exists, >> it is >> > a slippery slope towards starting to rely on those artifacts for not >> only >> > development but also releases. >> > >> > 2. Reduces the likelihood of fork-causing events >> > If one's dev branch builds against master snapshot artifacts, one is >> more >> > likely to notice a disruptive change sooner. This then allows one to >> start >> > a conversation about the disruption as early as possible post merge (in >> a >> > perfect world, it would be noticed pre-merge but that's a separate >> topic). >> > If one waits for releases to test new features and confirm if they are >> > disruptive, this makes adaptation harder. The developer who added the >> > disruptive change is less likely to be available and thinking about the >> > same issues and the pressure to push a release will make this extra >> > painful. This kind of situation increases the likelihood of hard forks. >> > I've experienced this first hand several times and hope to never repeat >> it >> > again. >> > >> > 3. Reduces the likelihood of accidental breaking changes (or awkward >> > situations) >> > Similar to 2 above, if downstream projects depend on released versions >> > during development, it increases the likelihood of a breaking change >> being >> > accidentally introduced. And on the opposite side, the introduction of >> new >> > changes may turn out to be problematic or challenging. Catching those >> items >> > before release decreases the likelihood of introducing an API and then >> > having to back it out afterwards (and dealing with compat implications). >> > With snapshot artifacts, I believe people are more likely to catch these >> > problems sooner. >> > >> > 4. Increase interest/effort towards releases >> > Reasonable people won't release against a snapshot release (my $0.02). >> If >> > these people develop more often against Calcite master (as opposed to >> their >> > own fork), they are more likely to push for a release to help them >> > accommodate their own releasing needs. >> > >> > Of course, these are all just my own theories about this stuff. I >> > unfortunately don't have any numbers to back this up. Nonetheless, I >> think >> > these benefits outweigh associated costs or potential downsides. >> > >> > Jacques >> > >> > >> > >> > >> > On Sun, Dec 12, 2021 at 2:08 PM Julian Hyde <jhyde.apa...@gmail.com> >> wrote: >> > >> > > I have no problems with the technical side of this. And I am >> supportive of >> > > one-off snapshots, e.g. a snapshot for testing made a week or two >> ahead of >> > > a release. >> > > >> > > But there are some downsides with regular, automated snapshots, and I >> am >> > > concerned that projects and companies will become dependent on them, >> for >> > > the following reasons: >> > > >> > > 1. Snapshots can change without notice. (Bugs may be introduced, APIs >> > > removed without notice.) This is mostly the problem for the downstream >> > > project — in other words, caveat emptor — but may cause work for >> > > committers. It’s certainly a bad idea to base a release on a snapshot. >> > > >> > > 2. Snapshots are not releases. The Apache license does not apply to >> code >> > > that has not been released. >> > > >> > > 3. If people get too comfortable using snapshots, there will be fewer >> > > resources to make official releases. >> > > >> > > Is the additional convenience worth these downsides? Just asking. I’m >> > > prepared to be persuaded. >> > > >> > > Julian >> > > >> > > >> > > >> > > > On Dec 12, 2021, at 10:23 AM, Jacques Nadeau <jacq...@apache.org> >> wrote: >> > > > >> > > > Hey All, >> > > > >> > > > I've been wanting to do more testing against master for integration >> > > > purposes and right now that requires private builds. As such, I >> opened >> > > > CALCITE-4934 [1] to add support for automatic snapshot builds >> deployed to >> > > > the Apache snapshot Maven repository on master merges. As noted in >> the >> > > > ticket, this used to be the case many years ago (CALCITE-351 >> enabled it). >> > > > The right bits are now enabled in GitHub to make this effortless >> and I've >> > > > confirmed that this looks like it is working correctly [2][3]. >> > > > >> > > > Before merging I wanted to make sure that people were comfortable >> with >> > > this >> > > > addition since it changes build infra. The PR is pretty trivial [4] >> and >> > > > modeled off other Apache projects. >> > > > >> > > > Lastly, note that snapshots are *not* Apache Releases and shouldn't >> be >> > > > presented as such in docs, etc. >> > > > >> > > > Please raise your hand if you have any concerns. >> > > > >> > > > Thanks, >> > > > Jacques >> > > > >> > > > >> > > > [1] https://issues.apache.org/jira/browse/CALCITE-4934 >> > > > [2] >> > > >> https://github.com/apache/calcite/runs/4499040456?check_suite_focus=true >> > > > [3] >> > > > >> > > >> https://repository.apache.org/content/groups/snapshots/org/apache/calcite/calcite-core/1.29.0-SNAPSHOT/ >> > > > [4] https://github.com/apache/calcite/pull/2641 >> > > >> > > >> >
