In case it's not clear where `comdev@` is (it wasn't at all to me), here's
the thread Julian referenced:
https://lists.apache.org/thread.html/rf12538ef0f60f7257e63391e5d4962a6156564020c99d3dfb193f4d7%40%3Cdev.community.apache.org%3E
Neal
On Mon, May 3, 2021 at 1:25 PM Julian Hyde wrote:
> If yo
If you think that a release every two weeks, following the standard
voting-on-signed-tarball process, is not too onerous, then we're good.
If you read my email thread on comdev@ you will see that SkyWalking
has been following a similar process.
On Mon, May 3, 2021 at 11:41 AM Andrew Lamb wrote:
>
There have been some great discussions on the document.
I would say the major unresolved questions are
1. What branching strategy would best balance frequent releases,
maintainers' time, and contributors' time.
2. (related) How do we handle breaking API changes between major releases
that aren't
Hi,
my two cents: at my previous workplace (Tresorit) we created releases every
week and that process was even heavier including cross
platform verification and approval, a 8-12 hours long dedicated manual QA
process, discussions with the marketing and support teams.
Open source is certainly diffe
Micah and Julian, thank you both for your thoughts.
I largely agree with Micah; While the Apache process may be heavy weight
in certain aspects, I think we can achieve Rust releases every 2 week
within that framework.
As I doubt very much we'll get it perfect on the first try, I was
envisioning
>
> Apache releases are quite heavyweight, so
> work best at a frequency of 2 - 3 months, whereas (IIUC) Rust
> developers expect a more lightweight release on a weekly cadence.
Thanks, I think clarifications on requirements are helpful. IIUC is is
actually a 2 week cadence which is still fast b
The main tension is not in the proposal but the requirements. It's a
classic impedance mismatch. Apache releases are quite heavyweight, so
work best at a frequency of 2 - 3 months, whereas (IIUC) Rust
developers expect a more lightweight release on a weekly cadence. I
was trying to find other proje
Hi Julian,
I didn't read this proposal as being in tension with apache releases. It
sounds like the intention is to hold a vote every two weeks to verify a
release artifacts? But maybe I misread or missed something. Were do you
think the tension lies? Is it also producing the signed source artif
(Removing user@ from cc. I think this is mainly a dev@ issue.)
I believe there are some tensions between this process and the Apache
process. In particular, Apache releases tend to be a signed source
distribution (tarball) that at least three PMC members download and
verify. I totally understand w
I propose regularly releasing, every 2 weeks, minor and patch releases of
the arrow-rs crate, following the semver versioning scheme used by the rest
of the Rust ecosystem. I have written a proposal[1] describing how this
might work.
Feedback and comments most welcome.
Andrew
[1]
https://docs.g
10 matches
Mail list logo
