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 > > > > > > >
