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

Reply via email to