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