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