On Sun, Jan 6, 2019 at 12:18 PM Chao Sun <sunc...@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 <m...@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 > > > <wesmck...@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 <sunc...@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 <wesmck...@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 <k...@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 > > > ><caf6ot1e5gixah8qgcnubyscnadvscyiwm5jqpbss6yzmajz...@mail.gmail.com> > > > >> > > "[Rust] crate versions and release process" on Wed, 2 Jan 2019 > > > >> > 21:27:45 -0800, > > > >> > > Chao Sun <sunc...@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 > > > >> > > >
