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 <wesmck...@gmail.com> wrote: > 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 > > > > >> > > > > >
