You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@arrow.apache.org by Chao Sun <su...@apache.org> on 2019/01/03 05:27:45 UTC
[Rust] crate versions and release process
Hi,
This is related to an earlier email I sent regarding separating the Rust
implementation into sub crates. See some early discussions in this PR
[1]. As we could have multiple crates for the project in future (e.g.,
arrow, parquet, orc, gandiva), I'm wondering whether we can keep different
versions for these crates. For instance, the parquet crate use to have
version 0.4.2 before merging into arrow, and I think it's better to
maintain the continuity there.
Another thing is about release cycles. I understand that it is best to keep
the release cycles for these crates the same as arrow's. However, it's
possible in future that we may need a minor release for a critical bug fix
of a particular crate, and to follow the overall release process for that
seems like an overkill and not quite feasible.
Therefore, I'm proposing to:
1. allow different versions for sub-crates.
2. follow the overall release schedule, but maintain the flexibility of
doing separate releases when necessary.
Thought?
Chao
[1]: https://github.com/apache/arrow/pull/3291#issuecomment-450950275
Re: [Rust] crate versions and release process
Posted by Chao Sun <su...@apache.org>.
OK, I don't want to add much extra work to the release process. Let's use
the single version for now then and perhaps revisit this in future.
On Sun, Jan 6, 2019 at 10:41 AM Wes McKinney <we...@gmail.com> wrote:
> On Sun, Jan 6, 2019 at 12:18 PM Chao Sun <su...@apache.org> wrote:
> >
> > I think version number (in terms of major.minor.fix) does carry a meaning
> > and IMO it is less desirable to apply a single value for all the
> > sub-modules. Ideally all these should be marching at the same speed but
> in
> > reality that may not be the case.
>
> I don't think we have the maintainer bandwidth to do anything else
> right now -- it's enough work to get just the single main repo release
> out. If the Rust community grows and there are PMC members working on
> Rust who want to manage independent releases, they are free to do
> that.
>
> > Besides critical bug/security fixes, at some point we may want to claim
> > that some module has reached a stable version and hence 1.X.X while
> others
> > should still stay at 0.X.X.
>
> I would guess we are quite a ways away from this goal, we're talking
> sometime 2020 at earliest. I'm concerned that adding a bunch of
> maintainer overhead right now will make things move more slowly
> without clear benefit.
>
> >
> > On the Rust side, we should strive to keep the arrow crate version the
> same
> > as the main release version, but perhaps we can allow differences in
> other
> > "supporting" crates?
>
> Unless the supporting crates have decoupled Apache releases I think
> using different versions is only going to be confusing. Having
> separate Apache releases is only really practical if there are willing
> release managers on the PMC.
>
> >
> > On Sun, Jan 6, 2019 at 3:48 AM Uwe L. Korn <ma...@uwekorn.com> wrote:
> >
> > > This is definitely possible for Apache projects. Currently we still
> have
> > > two releases: "Arrow without JS" and "Arrow JS". We can have separate
> > > release votes for security and small fixes for subcrates. There are
> mainly
> > > two things that "limit us":
> > >
> > > 1. We still need to do the release votes (there are some special
> > > exemptions for security releases)
> > > 2. We would need our release and verification scripts to cater for
> single
> > > artefact releases. In the case of a single Rust crate, this might be a
> bit
> > > simpler but we still need to write these scripts.
> > >
> > > Uwe
> > >
> > > On Sun, Jan 6, 2019, at 12:32 PM, Marco Neumann wrote:
> > > > The main question is: do we want independent reales (for security and
> > > > severe bugs) or not?
> > > >
> > > > If so, what about the following versioning scheme:
> > > >
> > > > Major.Minor.Fix
> > > >
> > > > Major and minor are in-sync for all languages and libraries/crates
> and
> > > > can be featured using in blog posts and other channels. Fix releases
> can
> > > > diverge and are usually not featured (except for security bugs and
> other
> > > > severe problems).
> > > >
> > > > Would this be possible for an apache project?
> > > >
> > > > On January 6, 2019 5:02:56 AM GMT+01:00, Wes McKinney
> > > > <we...@gmail.com> wrote:
> > > > >Again, this is an Apache process question, and I need to defer to
> more
> > > > >experienced people. It might be confusing to have Apache Arrow X.Y.Z
> > > > >and artifacts deriving from that release with different version
> > > > >numbers. I don't see the upside to having different version numbers
> > > > >unless you intend to release them independently
> > > > >
> > > > >On Sat, Jan 5, 2019 at 4:17 PM Chao Sun <su...@apache.org> wrote:
> > > > >>
> > > > >> Hi Wes, I was only thinking about having different versions for
> the
> > > > >> subcrates but still the same release process for them. Does
> version
> > > > >number
> > > > >> make a difference in this case?
> > > > >>
> > > > >> On Sat, Jan 5, 2019 at 12:17 PM Wes McKinney <wesmckinn@gmail.com
> >
> > > > >wrote:
> > > > >>
> > > > >> > > For instance, the parquet crate use to have version 0.4.2
> before
> > > > >merging
> > > > >> > into arrow, and I think it's better to maintain the continuity
> > > > >there.
> > > > >> >
> > > > >> > This could be a little bit problematic from an ASF release
> point of
> > > > >> > view. Do you want to do separate release votes for the subcrates
> > > > >(this
> > > > >> > creates extra work for maintainers)? If not then it is probably
> > > > >best
> > > > >> > to use the same version everywhere.
> > > > >> >
> > > > >> > - Wes
> > > > >> >
> > > > >> > On Sat, Jan 5, 2019 at 1:32 AM Kouhei Sutou <kou@clear-code.com
> >
> > > > >wrote:
> > > > >> > >
> > > > >> > > Hi,
> > > > >> > >
> > > > >> > > I have no opinion about version of sub-crates.
> > > > >> > >
> > > > >> > > When should we bump version of sub-crates? Is it a matter of
> > > > >> > > Rust developers rather than release managers?
> > > > >> > >
> > > > >> > > I just want to know whether release managers need to care
> > > > >> > > version of sub-crates or not.
> > > > >> > >
> > > > >> > >
> > > > >> > > Thanks,
> > > > >> > > --
> > > > >> > > kou
> > > > >> > >
> > > > >> > > In
> > > > ><CAF6oT1e5gixaH8QGcNUbyScnADVscYiWm5jQpbsS6yzMaJzjcQ@mail.gmail.com
> >
> > > > >> > > "[Rust] crate versions and release process" on Wed, 2 Jan
> 2019
> > > > >> > 21:27:45 -0800,
> > > > >> > > Chao Sun <su...@apache.org> wrote:
> > > > >> > >
> > > > >> > > > Hi,
> > > > >> > > >
> > > > >> > > > This is related to an earlier email I sent regarding
> separating
> > > > >the
> > > > >> > Rust
> > > > >> > > > implementation into sub crates. See some early discussions
> in
> > > > >this PR
> > > > >> > > > [1]. As we could have multiple crates for the project in
> > > > >future (e.g.,
> > > > >> > > > arrow, parquet, orc, gandiva), I'm wondering whether we can
> > > > >keep
> > > > >> > different
> > > > >> > > > versions for these crates. For instance, the parquet crate
> use
> > > > >to have
> > > > >> > > > version 0.4.2 before merging into arrow, and I think it's
> > > > >better to
> > > > >> > > > maintain the continuity there.
> > > > >> > > >
> > > > >> > > > Another thing is about release cycles. I understand that it
> is
> > > > >best to
> > > > >> > keep
> > > > >> > > > the release cycles for these crates the same as arrow's.
> > > > >However, it's
> > > > >> > > > possible in future that we may need a minor release for a
> > > > >critical bug
> > > > >> > fix
> > > > >> > > > of a particular crate, and to follow the overall release
> > > > >process for
> > > > >> > that
> > > > >> > > > seems like an overkill and not quite feasible.
> > > > >> > > >
> > > > >> > > > Therefore, I'm proposing to:
> > > > >> > > > 1. allow different versions for sub-crates.
> > > > >> > > > 2. follow the overall release schedule, but maintain the
> > > > >flexibility of
> > > > >> > > > doing separate releases when necessary.
> > > > >> > > >
> > > > >> > > > Thought?
> > > > >> > > >
> > > > >> > > > Chao
> > > > >> > > >
> > > > >> > > > [1]:
> > > > >https://github.com/apache/arrow/pull/3291#issuecomment-450950275
> > > > >> >
> > >
>
Re: [Rust] crate versions and release process
Posted by Wes McKinney <we...@gmail.com>.
On Sun, Jan 6, 2019 at 12:18 PM Chao Sun <su...@apache.org> wrote:
>
> I think version number (in terms of major.minor.fix) does carry a meaning
> and IMO it is less desirable to apply a single value for all the
> sub-modules. Ideally all these should be marching at the same speed but in
> reality that may not be the case.
I don't think we have the maintainer bandwidth to do anything else
right now -- it's enough work to get just the single main repo release
out. If the Rust community grows and there are PMC members working on
Rust who want to manage independent releases, they are free to do
that.
> Besides critical bug/security fixes, at some point we may want to claim
> that some module has reached a stable version and hence 1.X.X while others
> should still stay at 0.X.X.
I would guess we are quite a ways away from this goal, we're talking
sometime 2020 at earliest. I'm concerned that adding a bunch of
maintainer overhead right now will make things move more slowly
without clear benefit.
>
> On the Rust side, we should strive to keep the arrow crate version the same
> as the main release version, but perhaps we can allow differences in other
> "supporting" crates?
Unless the supporting crates have decoupled Apache releases I think
using different versions is only going to be confusing. Having
separate Apache releases is only really practical if there are willing
release managers on the PMC.
>
> On Sun, Jan 6, 2019 at 3:48 AM Uwe L. Korn <ma...@uwekorn.com> wrote:
>
> > This is definitely possible for Apache projects. Currently we still have
> > two releases: "Arrow without JS" and "Arrow JS". We can have separate
> > release votes for security and small fixes for subcrates. There are mainly
> > two things that "limit us":
> >
> > 1. We still need to do the release votes (there are some special
> > exemptions for security releases)
> > 2. We would need our release and verification scripts to cater for single
> > artefact releases. In the case of a single Rust crate, this might be a bit
> > simpler but we still need to write these scripts.
> >
> > Uwe
> >
> > On Sun, Jan 6, 2019, at 12:32 PM, Marco Neumann wrote:
> > > The main question is: do we want independent reales (for security and
> > > severe bugs) or not?
> > >
> > > If so, what about the following versioning scheme:
> > >
> > > Major.Minor.Fix
> > >
> > > Major and minor are in-sync for all languages and libraries/crates and
> > > can be featured using in blog posts and other channels. Fix releases can
> > > diverge and are usually not featured (except for security bugs and other
> > > severe problems).
> > >
> > > Would this be possible for an apache project?
> > >
> > > On January 6, 2019 5:02:56 AM GMT+01:00, Wes McKinney
> > > <we...@gmail.com> wrote:
> > > >Again, this is an Apache process question, and I need to defer to more
> > > >experienced people. It might be confusing to have Apache Arrow X.Y.Z
> > > >and artifacts deriving from that release with different version
> > > >numbers. I don't see the upside to having different version numbers
> > > >unless you intend to release them independently
> > > >
> > > >On Sat, Jan 5, 2019 at 4:17 PM Chao Sun <su...@apache.org> wrote:
> > > >>
> > > >> Hi Wes, I was only thinking about having different versions for the
> > > >> subcrates but still the same release process for them. Does version
> > > >number
> > > >> make a difference in this case?
> > > >>
> > > >> On Sat, Jan 5, 2019 at 12:17 PM Wes McKinney <we...@gmail.com>
> > > >wrote:
> > > >>
> > > >> > > For instance, the parquet crate use to have version 0.4.2 before
> > > >merging
> > > >> > into arrow, and I think it's better to maintain the continuity
> > > >there.
> > > >> >
> > > >> > This could be a little bit problematic from an ASF release point of
> > > >> > view. Do you want to do separate release votes for the subcrates
> > > >(this
> > > >> > creates extra work for maintainers)? If not then it is probably
> > > >best
> > > >> > to use the same version everywhere.
> > > >> >
> > > >> > - Wes
> > > >> >
> > > >> > On Sat, Jan 5, 2019 at 1:32 AM Kouhei Sutou <ko...@clear-code.com>
> > > >wrote:
> > > >> > >
> > > >> > > Hi,
> > > >> > >
> > > >> > > I have no opinion about version of sub-crates.
> > > >> > >
> > > >> > > When should we bump version of sub-crates? Is it a matter of
> > > >> > > Rust developers rather than release managers?
> > > >> > >
> > > >> > > I just want to know whether release managers need to care
> > > >> > > version of sub-crates or not.
> > > >> > >
> > > >> > >
> > > >> > > Thanks,
> > > >> > > --
> > > >> > > kou
> > > >> > >
> > > >> > > In
> > > ><CA...@mail.gmail.com>
> > > >> > > "[Rust] crate versions and release process" on Wed, 2 Jan 2019
> > > >> > 21:27:45 -0800,
> > > >> > > Chao Sun <su...@apache.org> wrote:
> > > >> > >
> > > >> > > > Hi,
> > > >> > > >
> > > >> > > > This is related to an earlier email I sent regarding separating
> > > >the
> > > >> > Rust
> > > >> > > > implementation into sub crates. See some early discussions in
> > > >this PR
> > > >> > > > [1]. As we could have multiple crates for the project in
> > > >future (e.g.,
> > > >> > > > arrow, parquet, orc, gandiva), I'm wondering whether we can
> > > >keep
> > > >> > different
> > > >> > > > versions for these crates. For instance, the parquet crate use
> > > >to have
> > > >> > > > version 0.4.2 before merging into arrow, and I think it's
> > > >better to
> > > >> > > > maintain the continuity there.
> > > >> > > >
> > > >> > > > Another thing is about release cycles. I understand that it is
> > > >best to
> > > >> > keep
> > > >> > > > the release cycles for these crates the same as arrow's.
> > > >However, it's
> > > >> > > > possible in future that we may need a minor release for a
> > > >critical bug
> > > >> > fix
> > > >> > > > of a particular crate, and to follow the overall release
> > > >process for
> > > >> > that
> > > >> > > > seems like an overkill and not quite feasible.
> > > >> > > >
> > > >> > > > Therefore, I'm proposing to:
> > > >> > > > 1. allow different versions for sub-crates.
> > > >> > > > 2. follow the overall release schedule, but maintain the
> > > >flexibility of
> > > >> > > > doing separate releases when necessary.
> > > >> > > >
> > > >> > > > Thought?
> > > >> > > >
> > > >> > > > Chao
> > > >> > > >
> > > >> > > > [1]:
> > > >https://github.com/apache/arrow/pull/3291#issuecomment-450950275
> > > >> >
> >
Re: [Rust] crate versions and release process
Posted by Chao Sun <su...@apache.org>.
I think version number (in terms of major.minor.fix) does carry a meaning
and IMO it is less desirable to apply a single value for all the
sub-modules. Ideally all these should be marching at the same speed but in
reality that may not be the case.
Besides critical bug/security fixes, at some point we may want to claim
that some module has reached a stable version and hence 1.X.X while others
should still stay at 0.X.X.
On the Rust side, we should strive to keep the arrow crate version the same
as the main release version, but perhaps we can allow differences in other
"supporting" crates?
On Sun, Jan 6, 2019 at 3:48 AM Uwe L. Korn <ma...@uwekorn.com> wrote:
> This is definitely possible for Apache projects. Currently we still have
> two releases: "Arrow without JS" and "Arrow JS". We can have separate
> release votes for security and small fixes for subcrates. There are mainly
> two things that "limit us":
>
> 1. We still need to do the release votes (there are some special
> exemptions for security releases)
> 2. We would need our release and verification scripts to cater for single
> artefact releases. In the case of a single Rust crate, this might be a bit
> simpler but we still need to write these scripts.
>
> Uwe
>
> On Sun, Jan 6, 2019, at 12:32 PM, Marco Neumann wrote:
> > The main question is: do we want independent reales (for security and
> > severe bugs) or not?
> >
> > If so, what about the following versioning scheme:
> >
> > Major.Minor.Fix
> >
> > Major and minor are in-sync for all languages and libraries/crates and
> > can be featured using in blog posts and other channels. Fix releases can
> > diverge and are usually not featured (except for security bugs and other
> > severe problems).
> >
> > Would this be possible for an apache project?
> >
> > On January 6, 2019 5:02:56 AM GMT+01:00, Wes McKinney
> > <we...@gmail.com> wrote:
> > >Again, this is an Apache process question, and I need to defer to more
> > >experienced people. It might be confusing to have Apache Arrow X.Y.Z
> > >and artifacts deriving from that release with different version
> > >numbers. I don't see the upside to having different version numbers
> > >unless you intend to release them independently
> > >
> > >On Sat, Jan 5, 2019 at 4:17 PM Chao Sun <su...@apache.org> wrote:
> > >>
> > >> Hi Wes, I was only thinking about having different versions for the
> > >> subcrates but still the same release process for them. Does version
> > >number
> > >> make a difference in this case?
> > >>
> > >> On Sat, Jan 5, 2019 at 12:17 PM Wes McKinney <we...@gmail.com>
> > >wrote:
> > >>
> > >> > > For instance, the parquet crate use to have version 0.4.2 before
> > >merging
> > >> > into arrow, and I think it's better to maintain the continuity
> > >there.
> > >> >
> > >> > This could be a little bit problematic from an ASF release point of
> > >> > view. Do you want to do separate release votes for the subcrates
> > >(this
> > >> > creates extra work for maintainers)? If not then it is probably
> > >best
> > >> > to use the same version everywhere.
> > >> >
> > >> > - Wes
> > >> >
> > >> > On Sat, Jan 5, 2019 at 1:32 AM Kouhei Sutou <ko...@clear-code.com>
> > >wrote:
> > >> > >
> > >> > > Hi,
> > >> > >
> > >> > > I have no opinion about version of sub-crates.
> > >> > >
> > >> > > When should we bump version of sub-crates? Is it a matter of
> > >> > > Rust developers rather than release managers?
> > >> > >
> > >> > > I just want to know whether release managers need to care
> > >> > > version of sub-crates or not.
> > >> > >
> > >> > >
> > >> > > Thanks,
> > >> > > --
> > >> > > kou
> > >> > >
> > >> > > In
> > ><CA...@mail.gmail.com>
> > >> > > "[Rust] crate versions and release process" on Wed, 2 Jan 2019
> > >> > 21:27:45 -0800,
> > >> > > Chao Sun <su...@apache.org> wrote:
> > >> > >
> > >> > > > Hi,
> > >> > > >
> > >> > > > This is related to an earlier email I sent regarding separating
> > >the
> > >> > Rust
> > >> > > > implementation into sub crates. See some early discussions in
> > >this PR
> > >> > > > [1]. As we could have multiple crates for the project in
> > >future (e.g.,
> > >> > > > arrow, parquet, orc, gandiva), I'm wondering whether we can
> > >keep
> > >> > different
> > >> > > > versions for these crates. For instance, the parquet crate use
> > >to have
> > >> > > > version 0.4.2 before merging into arrow, and I think it's
> > >better to
> > >> > > > maintain the continuity there.
> > >> > > >
> > >> > > > Another thing is about release cycles. I understand that it is
> > >best to
> > >> > keep
> > >> > > > the release cycles for these crates the same as arrow's.
> > >However, it's
> > >> > > > possible in future that we may need a minor release for a
> > >critical bug
> > >> > fix
> > >> > > > of a particular crate, and to follow the overall release
> > >process for
> > >> > that
> > >> > > > seems like an overkill and not quite feasible.
> > >> > > >
> > >> > > > Therefore, I'm proposing to:
> > >> > > > 1. allow different versions for sub-crates.
> > >> > > > 2. follow the overall release schedule, but maintain the
> > >flexibility of
> > >> > > > doing separate releases when necessary.
> > >> > > >
> > >> > > > Thought?
> > >> > > >
> > >> > > > Chao
> > >> > > >
> > >> > > > [1]:
> > >https://github.com/apache/arrow/pull/3291#issuecomment-450950275
> > >> >
>
Re: [Rust] crate versions and release process
Posted by "Uwe L. Korn" <ma...@uwekorn.com>.
This is definitely possible for Apache projects. Currently we still have two releases: "Arrow without JS" and "Arrow JS". We can have separate release votes for security and small fixes for subcrates. There are mainly two things that "limit us":
1. We still need to do the release votes (there are some special exemptions for security releases)
2. We would need our release and verification scripts to cater for single artefact releases. In the case of a single Rust crate, this might be a bit simpler but we still need to write these scripts.
Uwe
On Sun, Jan 6, 2019, at 12:32 PM, Marco Neumann wrote:
> The main question is: do we want independent reales (for security and
> severe bugs) or not?
>
> If so, what about the following versioning scheme:
>
> Major.Minor.Fix
>
> Major and minor are in-sync for all languages and libraries/crates and
> can be featured using in blog posts and other channels. Fix releases can
> diverge and are usually not featured (except for security bugs and other
> severe problems).
>
> Would this be possible for an apache project?
>
> On January 6, 2019 5:02:56 AM GMT+01:00, Wes McKinney
> <we...@gmail.com> wrote:
> >Again, this is an Apache process question, and I need to defer to more
> >experienced people. It might be confusing to have Apache Arrow X.Y.Z
> >and artifacts deriving from that release with different version
> >numbers. I don't see the upside to having different version numbers
> >unless you intend to release them independently
> >
> >On Sat, Jan 5, 2019 at 4:17 PM Chao Sun <su...@apache.org> wrote:
> >>
> >> Hi Wes, I was only thinking about having different versions for the
> >> subcrates but still the same release process for them. Does version
> >number
> >> make a difference in this case?
> >>
> >> On Sat, Jan 5, 2019 at 12:17 PM Wes McKinney <we...@gmail.com>
> >wrote:
> >>
> >> > > For instance, the parquet crate use to have version 0.4.2 before
> >merging
> >> > into arrow, and I think it's better to maintain the continuity
> >there.
> >> >
> >> > This could be a little bit problematic from an ASF release point of
> >> > view. Do you want to do separate release votes for the subcrates
> >(this
> >> > creates extra work for maintainers)? If not then it is probably
> >best
> >> > to use the same version everywhere.
> >> >
> >> > - Wes
> >> >
> >> > On Sat, Jan 5, 2019 at 1:32 AM Kouhei Sutou <ko...@clear-code.com>
> >wrote:
> >> > >
> >> > > Hi,
> >> > >
> >> > > I have no opinion about version of sub-crates.
> >> > >
> >> > > When should we bump version of sub-crates? Is it a matter of
> >> > > Rust developers rather than release managers?
> >> > >
> >> > > I just want to know whether release managers need to care
> >> > > version of sub-crates or not.
> >> > >
> >> > >
> >> > > Thanks,
> >> > > --
> >> > > kou
> >> > >
> >> > > In
> ><CA...@mail.gmail.com>
> >> > > "[Rust] crate versions and release process" on Wed, 2 Jan 2019
> >> > 21:27:45 -0800,
> >> > > Chao Sun <su...@apache.org> wrote:
> >> > >
> >> > > > Hi,
> >> > > >
> >> > > > This is related to an earlier email I sent regarding separating
> >the
> >> > Rust
> >> > > > implementation into sub crates. See some early discussions in
> >this PR
> >> > > > [1]. As we could have multiple crates for the project in
> >future (e.g.,
> >> > > > arrow, parquet, orc, gandiva), I'm wondering whether we can
> >keep
> >> > different
> >> > > > versions for these crates. For instance, the parquet crate use
> >to have
> >> > > > version 0.4.2 before merging into arrow, and I think it's
> >better to
> >> > > > maintain the continuity there.
> >> > > >
> >> > > > Another thing is about release cycles. I understand that it is
> >best to
> >> > keep
> >> > > > the release cycles for these crates the same as arrow's.
> >However, it's
> >> > > > possible in future that we may need a minor release for a
> >critical bug
> >> > fix
> >> > > > of a particular crate, and to follow the overall release
> >process for
> >> > that
> >> > > > seems like an overkill and not quite feasible.
> >> > > >
> >> > > > Therefore, I'm proposing to:
> >> > > > 1. allow different versions for sub-crates.
> >> > > > 2. follow the overall release schedule, but maintain the
> >flexibility of
> >> > > > doing separate releases when necessary.
> >> > > >
> >> > > > Thought?
> >> > > >
> >> > > > Chao
> >> > > >
> >> > > > [1]:
> >https://github.com/apache/arrow/pull/3291#issuecomment-450950275
> >> >
Re: [Rust] crate versions and release process
Posted by Marco Neumann <ma...@crepererum.net.INVALID>.
The main question is: do we want independent reales (for security and severe bugs) or not?
If so, what about the following versioning scheme:
Major.Minor.Fix
Major and minor are in-sync for all languages and libraries/crates and can be featured using in blog posts and other channels. Fix releases can diverge and are usually not featured (except for security bugs and other severe problems).
Would this be possible for an apache project?
On January 6, 2019 5:02:56 AM GMT+01:00, Wes McKinney <we...@gmail.com> wrote:
>Again, this is an Apache process question, and I need to defer to more
>experienced people. It might be confusing to have Apache Arrow X.Y.Z
>and artifacts deriving from that release with different version
>numbers. I don't see the upside to having different version numbers
>unless you intend to release them independently
>
>On Sat, Jan 5, 2019 at 4:17 PM Chao Sun <su...@apache.org> wrote:
>>
>> Hi Wes, I was only thinking about having different versions for the
>> subcrates but still the same release process for them. Does version
>number
>> make a difference in this case?
>>
>> On Sat, Jan 5, 2019 at 12:17 PM Wes McKinney <we...@gmail.com>
>wrote:
>>
>> > > For instance, the parquet crate use to have version 0.4.2 before
>merging
>> > into arrow, and I think it's better to maintain the continuity
>there.
>> >
>> > This could be a little bit problematic from an ASF release point of
>> > view. Do you want to do separate release votes for the subcrates
>(this
>> > creates extra work for maintainers)? If not then it is probably
>best
>> > to use the same version everywhere.
>> >
>> > - Wes
>> >
>> > On Sat, Jan 5, 2019 at 1:32 AM Kouhei Sutou <ko...@clear-code.com>
>wrote:
>> > >
>> > > Hi,
>> > >
>> > > I have no opinion about version of sub-crates.
>> > >
>> > > When should we bump version of sub-crates? Is it a matter of
>> > > Rust developers rather than release managers?
>> > >
>> > > I just want to know whether release managers need to care
>> > > version of sub-crates or not.
>> > >
>> > >
>> > > Thanks,
>> > > --
>> > > kou
>> > >
>> > > In
><CA...@mail.gmail.com>
>> > > "[Rust] crate versions and release process" on Wed, 2 Jan 2019
>> > 21:27:45 -0800,
>> > > Chao Sun <su...@apache.org> wrote:
>> > >
>> > > > Hi,
>> > > >
>> > > > This is related to an earlier email I sent regarding separating
>the
>> > Rust
>> > > > implementation into sub crates. See some early discussions in
>this PR
>> > > > [1]. As we could have multiple crates for the project in
>future (e.g.,
>> > > > arrow, parquet, orc, gandiva), I'm wondering whether we can
>keep
>> > different
>> > > > versions for these crates. For instance, the parquet crate use
>to have
>> > > > version 0.4.2 before merging into arrow, and I think it's
>better to
>> > > > maintain the continuity there.
>> > > >
>> > > > Another thing is about release cycles. I understand that it is
>best to
>> > keep
>> > > > the release cycles for these crates the same as arrow's.
>However, it's
>> > > > possible in future that we may need a minor release for a
>critical bug
>> > fix
>> > > > of a particular crate, and to follow the overall release
>process for
>> > that
>> > > > seems like an overkill and not quite feasible.
>> > > >
>> > > > Therefore, I'm proposing to:
>> > > > 1. allow different versions for sub-crates.
>> > > > 2. follow the overall release schedule, but maintain the
>flexibility of
>> > > > doing separate releases when necessary.
>> > > >
>> > > > Thought?
>> > > >
>> > > > Chao
>> > > >
>> > > > [1]:
>https://github.com/apache/arrow/pull/3291#issuecomment-450950275
>> >
Re: [Rust] crate versions and release process
Posted by Wes McKinney <we...@gmail.com>.
Again, this is an Apache process question, and I need to defer to more
experienced people. It might be confusing to have Apache Arrow X.Y.Z
and artifacts deriving from that release with different version
numbers. I don't see the upside to having different version numbers
unless you intend to release them independently
On Sat, Jan 5, 2019 at 4:17 PM Chao Sun <su...@apache.org> wrote:
>
> Hi Wes, I was only thinking about having different versions for the
> subcrates but still the same release process for them. Does version number
> make a difference in this case?
>
> On Sat, Jan 5, 2019 at 12:17 PM Wes McKinney <we...@gmail.com> wrote:
>
> > > For instance, the parquet crate use to have version 0.4.2 before merging
> > into arrow, and I think it's better to maintain the continuity there.
> >
> > This could be a little bit problematic from an ASF release point of
> > view. Do you want to do separate release votes for the subcrates (this
> > creates extra work for maintainers)? If not then it is probably best
> > to use the same version everywhere.
> >
> > - Wes
> >
> > On Sat, Jan 5, 2019 at 1:32 AM Kouhei Sutou <ko...@clear-code.com> wrote:
> > >
> > > Hi,
> > >
> > > I have no opinion about version of sub-crates.
> > >
> > > When should we bump version of sub-crates? Is it a matter of
> > > Rust developers rather than release managers?
> > >
> > > I just want to know whether release managers need to care
> > > version of sub-crates or not.
> > >
> > >
> > > Thanks,
> > > --
> > > kou
> > >
> > > In <CA...@mail.gmail.com>
> > > "[Rust] crate versions and release process" on Wed, 2 Jan 2019
> > 21:27:45 -0800,
> > > Chao Sun <su...@apache.org> wrote:
> > >
> > > > Hi,
> > > >
> > > > This is related to an earlier email I sent regarding separating the
> > Rust
> > > > implementation into sub crates. See some early discussions in this PR
> > > > [1]. As we could have multiple crates for the project in future (e.g.,
> > > > arrow, parquet, orc, gandiva), I'm wondering whether we can keep
> > different
> > > > versions for these crates. For instance, the parquet crate use to have
> > > > version 0.4.2 before merging into arrow, and I think it's better to
> > > > maintain the continuity there.
> > > >
> > > > Another thing is about release cycles. I understand that it is best to
> > keep
> > > > the release cycles for these crates the same as arrow's. However, it's
> > > > possible in future that we may need a minor release for a critical bug
> > fix
> > > > of a particular crate, and to follow the overall release process for
> > that
> > > > seems like an overkill and not quite feasible.
> > > >
> > > > Therefore, I'm proposing to:
> > > > 1. allow different versions for sub-crates.
> > > > 2. follow the overall release schedule, but maintain the flexibility of
> > > > doing separate releases when necessary.
> > > >
> > > > Thought?
> > > >
> > > > Chao
> > > >
> > > > [1]: https://github.com/apache/arrow/pull/3291#issuecomment-450950275
> >
Re: [Rust] crate versions and release process
Posted by Chao Sun <su...@apache.org>.
Hi Wes, I was only thinking about having different versions for the
subcrates but still the same release process for them. Does version number
make a difference in this case?
On Sat, Jan 5, 2019 at 12:17 PM Wes McKinney <we...@gmail.com> wrote:
> > For instance, the parquet crate use to have version 0.4.2 before merging
> into arrow, and I think it's better to maintain the continuity there.
>
> This could be a little bit problematic from an ASF release point of
> view. Do you want to do separate release votes for the subcrates (this
> creates extra work for maintainers)? If not then it is probably best
> to use the same version everywhere.
>
> - Wes
>
> On Sat, Jan 5, 2019 at 1:32 AM Kouhei Sutou <ko...@clear-code.com> wrote:
> >
> > Hi,
> >
> > I have no opinion about version of sub-crates.
> >
> > When should we bump version of sub-crates? Is it a matter of
> > Rust developers rather than release managers?
> >
> > I just want to know whether release managers need to care
> > version of sub-crates or not.
> >
> >
> > Thanks,
> > --
> > kou
> >
> > In <CA...@mail.gmail.com>
> > "[Rust] crate versions and release process" on Wed, 2 Jan 2019
> 21:27:45 -0800,
> > Chao Sun <su...@apache.org> wrote:
> >
> > > Hi,
> > >
> > > This is related to an earlier email I sent regarding separating the
> Rust
> > > implementation into sub crates. See some early discussions in this PR
> > > [1]. As we could have multiple crates for the project in future (e.g.,
> > > arrow, parquet, orc, gandiva), I'm wondering whether we can keep
> different
> > > versions for these crates. For instance, the parquet crate use to have
> > > version 0.4.2 before merging into arrow, and I think it's better to
> > > maintain the continuity there.
> > >
> > > Another thing is about release cycles. I understand that it is best to
> keep
> > > the release cycles for these crates the same as arrow's. However, it's
> > > possible in future that we may need a minor release for a critical bug
> fix
> > > of a particular crate, and to follow the overall release process for
> that
> > > seems like an overkill and not quite feasible.
> > >
> > > Therefore, I'm proposing to:
> > > 1. allow different versions for sub-crates.
> > > 2. follow the overall release schedule, but maintain the flexibility of
> > > doing separate releases when necessary.
> > >
> > > Thought?
> > >
> > > Chao
> > >
> > > [1]: https://github.com/apache/arrow/pull/3291#issuecomment-450950275
>
Re: [Rust] crate versions and release process
Posted by Wes McKinney <we...@gmail.com>.
> For instance, the parquet crate use to have version 0.4.2 before merging into arrow, and I think it's better to maintain the continuity there.
This could be a little bit problematic from an ASF release point of
view. Do you want to do separate release votes for the subcrates (this
creates extra work for maintainers)? If not then it is probably best
to use the same version everywhere.
- Wes
On Sat, Jan 5, 2019 at 1:32 AM Kouhei Sutou <ko...@clear-code.com> wrote:
>
> Hi,
>
> I have no opinion about version of sub-crates.
>
> When should we bump version of sub-crates? Is it a matter of
> Rust developers rather than release managers?
>
> I just want to know whether release managers need to care
> version of sub-crates or not.
>
>
> Thanks,
> --
> kou
>
> In <CA...@mail.gmail.com>
> "[Rust] crate versions and release process" on Wed, 2 Jan 2019 21:27:45 -0800,
> Chao Sun <su...@apache.org> wrote:
>
> > Hi,
> >
> > This is related to an earlier email I sent regarding separating the Rust
> > implementation into sub crates. See some early discussions in this PR
> > [1]. As we could have multiple crates for the project in future (e.g.,
> > arrow, parquet, orc, gandiva), I'm wondering whether we can keep different
> > versions for these crates. For instance, the parquet crate use to have
> > version 0.4.2 before merging into arrow, and I think it's better to
> > maintain the continuity there.
> >
> > Another thing is about release cycles. I understand that it is best to keep
> > the release cycles for these crates the same as arrow's. However, it's
> > possible in future that we may need a minor release for a critical bug fix
> > of a particular crate, and to follow the overall release process for that
> > seems like an overkill and not quite feasible.
> >
> > Therefore, I'm proposing to:
> > 1. allow different versions for sub-crates.
> > 2. follow the overall release schedule, but maintain the flexibility of
> > doing separate releases when necessary.
> >
> > Thought?
> >
> > Chao
> >
> > [1]: https://github.com/apache/arrow/pull/3291#issuecomment-450950275
Re: [Rust] crate versions and release process
Posted by Kouhei Sutou <ko...@clear-code.com>.
Hi,
I have no opinion about version of sub-crates.
When should we bump version of sub-crates? Is it a matter of
Rust developers rather than release managers?
I just want to know whether release managers need to care
version of sub-crates or not.
Thanks,
--
kou
In <CA...@mail.gmail.com>
"[Rust] crate versions and release process" on Wed, 2 Jan 2019 21:27:45 -0800,
Chao Sun <su...@apache.org> wrote:
> Hi,
>
> This is related to an earlier email I sent regarding separating the Rust
> implementation into sub crates. See some early discussions in this PR
> [1]. As we could have multiple crates for the project in future (e.g.,
> arrow, parquet, orc, gandiva), I'm wondering whether we can keep different
> versions for these crates. For instance, the parquet crate use to have
> version 0.4.2 before merging into arrow, and I think it's better to
> maintain the continuity there.
>
> Another thing is about release cycles. I understand that it is best to keep
> the release cycles for these crates the same as arrow's. However, it's
> possible in future that we may need a minor release for a critical bug fix
> of a particular crate, and to follow the overall release process for that
> seems like an overkill and not quite feasible.
>
> Therefore, I'm proposing to:
> 1. allow different versions for sub-crates.
> 2. follow the overall release schedule, but maintain the flexibility of
> doing separate releases when necessary.
>
> Thought?
>
> Chao
>
> [1]: https://github.com/apache/arrow/pull/3291#issuecomment-450950275
Re: [Rust] crate versions and release process
Posted by Marco Neumann <ma...@crepererum.net.INVALID>.
+1
The only thing to keep in mind is that versions are statement regarding API stability (aka semantic versioning). It is easy to forget about these things in a monorepo since you can fix all the breaking changes in the PR they got introduced. So whoever cuts the release must account for that and adjust the version numbers accordingly. I think we're likely counting up versions in roughly the same speed in the end (not a con, just a thought).
On January 4, 2019 9:37:33 AM GMT+01:00, "Krisztián Szűcs" <sz...@gmail.com> wrote:
>Agree, +1
>
>On Thu, Jan 3, 2019 at 10:49 PM Andy Grove <an...@gmail.com>
>wrote:
>
>> +1 from me. Keeping the code in a single repo makes sense but no need
>to
>> artificially keep versions numbers consistent between the sub-crates.
>>
>> Andy.
>>
>> On Wed, Jan 2, 2019 at 10:28 PM Chao Sun <su...@apache.org> wrote:
>>
>> > Hi,
>> >
>> > This is related to an earlier email I sent regarding separating the
>Rust
>> > implementation into sub crates. See some early discussions in this
>PR
>> > [1]. As we could have multiple crates for the project in future
>(e.g.,
>> > arrow, parquet, orc, gandiva), I'm wondering whether we can keep
>> different
>> > versions for these crates. For instance, the parquet crate use to
>have
>> > version 0.4.2 before merging into arrow, and I think it's better to
>> > maintain the continuity there.
>> >
>> > Another thing is about release cycles. I understand that it is best
>to
>> keep
>> > the release cycles for these crates the same as arrow's. However,
>it's
>> > possible in future that we may need a minor release for a critical
>bug
>> fix
>> > of a particular crate, and to follow the overall release process
>for that
>> > seems like an overkill and not quite feasible.
>> >
>> > Therefore, I'm proposing to:
>> > 1. allow different versions for sub-crates.
>> > 2. follow the overall release schedule, but maintain the
>flexibility of
>> > doing separate releases when necessary.
>> >
>> > Thought?
>> >
>> > Chao
>> >
>> > [1]:
>https://github.com/apache/arrow/pull/3291#issuecomment-450950275
>> >
>>
Re: [Rust] crate versions and release process
Posted by Krisztián Szűcs <sz...@gmail.com>.
Agree, +1
On Thu, Jan 3, 2019 at 10:49 PM Andy Grove <an...@gmail.com> wrote:
> +1 from me. Keeping the code in a single repo makes sense but no need to
> artificially keep versions numbers consistent between the sub-crates.
>
> Andy.
>
> On Wed, Jan 2, 2019 at 10:28 PM Chao Sun <su...@apache.org> wrote:
>
> > Hi,
> >
> > This is related to an earlier email I sent regarding separating the Rust
> > implementation into sub crates. See some early discussions in this PR
> > [1]. As we could have multiple crates for the project in future (e.g.,
> > arrow, parquet, orc, gandiva), I'm wondering whether we can keep
> different
> > versions for these crates. For instance, the parquet crate use to have
> > version 0.4.2 before merging into arrow, and I think it's better to
> > maintain the continuity there.
> >
> > Another thing is about release cycles. I understand that it is best to
> keep
> > the release cycles for these crates the same as arrow's. However, it's
> > possible in future that we may need a minor release for a critical bug
> fix
> > of a particular crate, and to follow the overall release process for that
> > seems like an overkill and not quite feasible.
> >
> > Therefore, I'm proposing to:
> > 1. allow different versions for sub-crates.
> > 2. follow the overall release schedule, but maintain the flexibility of
> > doing separate releases when necessary.
> >
> > Thought?
> >
> > Chao
> >
> > [1]: https://github.com/apache/arrow/pull/3291#issuecomment-450950275
> >
>
Re: [Rust] crate versions and release process
Posted by Andy Grove <an...@gmail.com>.
+1 from me. Keeping the code in a single repo makes sense but no need to
artificially keep versions numbers consistent between the sub-crates.
Andy.
On Wed, Jan 2, 2019 at 10:28 PM Chao Sun <su...@apache.org> wrote:
> Hi,
>
> This is related to an earlier email I sent regarding separating the Rust
> implementation into sub crates. See some early discussions in this PR
> [1]. As we could have multiple crates for the project in future (e.g.,
> arrow, parquet, orc, gandiva), I'm wondering whether we can keep different
> versions for these crates. For instance, the parquet crate use to have
> version 0.4.2 before merging into arrow, and I think it's better to
> maintain the continuity there.
>
> Another thing is about release cycles. I understand that it is best to keep
> the release cycles for these crates the same as arrow's. However, it's
> possible in future that we may need a minor release for a critical bug fix
> of a particular crate, and to follow the overall release process for that
> seems like an overkill and not quite feasible.
>
> Therefore, I'm proposing to:
> 1. allow different versions for sub-crates.
> 2. follow the overall release schedule, but maintain the flexibility of
> doing separate releases when necessary.
>
> Thought?
>
> Chao
>
> [1]: https://github.com/apache/arrow/pull/3291#issuecomment-450950275
>