Re: Automatic maven snapshot releases
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 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 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 >> 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 >> 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 >> wrote: >> > > > >> > > > Hey All, >> > > > >> > > > I've been wanting to do more testing against master for integration >>
Re: Automatic maven snapshot releases
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 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 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 > 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 > 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
Re: Automatic maven snapshot releases
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 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 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 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
Re: Automatic maven snapshot releases
I could add a basic build & test. Right now it is just a build and publish. Basic unit test suite seems like it would cover most common cases (where a rebase after pre-commit test causes a problem). Do you think it should be more thorough? Less? On Mon, Dec 13, 2021 at 9:52 AM Josh Elser wrote: > (top-posting to avoid extending the "how" divergence) > > Looks great and thanks for your care to avoid advertising them as > "releases". > > Only thing I was going to mention was about whether or not there's a > minimally "acceptable" test suite which can reliably run against master > before the new job would run. I know folks have been chasing this for > some time. > > On 12/12/21 1:23 PM, Jacques Nadeau 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 > > >
Re: Automatic maven snapshot releases
(top-posting to avoid extending the "how" divergence) Looks great and thanks for your care to avoid advertising them as "releases". Only thing I was going to mention was about whether or not there's a minimally "acceptable" test suite which can reliably run against master before the new job would run. I know folks have been chasing this for some time. On 12/12/21 1:23 PM, Jacques Nadeau 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
Re: Automatic maven snapshot releases
>Where is -Pasf defined/documented? https://calcite.apache.org/docs/howto.html#making-a-snapshot Vladimir
Re: Automatic maven snapshot releases
Let's keep the "should" conversation separate from the "how" conversation. *On should: * I understand that it worked in the past and then stopped working. I still think it is appropriate to confirm people are comfortable with enabling it again. *On how:* Vladimir, the github workflow job is configured to use ASF provided credentials, as standard per other ASF projects that push using Github workflows. My notes in the original post called out that this PR already works on the ASF repo. (The INFRA ticket linked to https://issues.apache.org/jira/browse/CALCITE-4934, https://issues.apache.org/jira/browse/INFRA-22601 enabled the credentials.) Where is -Pasf defined/documented? What are the credentials it is using (I'm assuming it is an env variable)? On Sun, Dec 12, 2021 at 9:36 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > Jacques, which credentials are you going to supply to publish the snapshots > to the ASF repository from GitHub? > > While I agree with moving towards GitHub actions, I would like to minimize > the use of ASF credentials in non-ASF environments. > > Luckily, ASF infra supplies the relevant credentials for publishing to ASF > Nexus, > so a mere "./gradlew -Pasf publish" at ASF Jenkins is enough to publish the > snapshots. > > Stamatis>In the past we used to have Jenkins jobs doing this > > The job was there, so we don't really need to discuss or vote on that. > I've created the corresponding Jenkins job here: > https://ci-builds.apache.org/job/Calcite/job/Calcite-snapshots/ > > It pulls GitHub every 5 minutes. > I am not sure if GitHub webhook integration would trigger the build (it > might need a config from INFRA), however, it is possible as well. > > Vladimir >
Re: Automatic maven snapshot releases
Jacques, which credentials are you going to supply to publish the snapshots to the ASF repository from GitHub? While I agree with moving towards GitHub actions, I would like to minimize the use of ASF credentials in non-ASF environments. Luckily, ASF infra supplies the relevant credentials for publishing to ASF Nexus, so a mere "./gradlew -Pasf publish" at ASF Jenkins is enough to publish the snapshots. Stamatis>In the past we used to have Jenkins jobs doing this The job was there, so we don't really need to discuss or vote on that. I've created the corresponding Jenkins job here: https://ci-builds.apache.org/job/Calcite/job/Calcite-snapshots/ It pulls GitHub every 5 minutes. I am not sure if GitHub webhook integration would trigger the build (it might need a config from INFRA), however, it is possible as well. Vladimir
Re: Automatic maven snapshot releases
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 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 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 > >
Re: Automatic maven snapshot releases
In the past we used to have Jenkins jobs doing this but I guess when Jenkins "died" all of these were lost. I am just seeing this as restoring the old behavior so it's fine with me. Personally, I never used them in the past but if those are helpful to other people then why not. Best, Stamatis On Sun, Dec 12, 2021 at 11:08 PM Julian Hyde 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 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 > >
Re: Automatic maven snapshot releases
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 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
Automatic maven snapshot releases
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
