Re: [DISCUSS] Release maintenance and lifecycle
Hello I find this proposal relevant. to clarify : > From 1.12.0 on, I'd like to propose maintaining *two* major versions > (i.e. 1.12.x and 1.11.x). That would allow us to deprecate and modify > APIs and give developers one whole major release to switch. this means to maintain 3 branches (1.13.0-SNAPSHOT (master), 1.12.x and 1.11.x) ? what about ? - master (1.13.0-SNAPSHOT) receive new feature + CVE + bug fixes + API breaking change (keeping old API with deprecated tag when possible) and remove old deprecated API (possibly not compatible with 1.12.x) - 1.12.x receive from master new feature + CVE + bug fixes (1.12.n+1 should stay compatible with 1.12.n, so, it won't receive breaking change). - 1.11.x receive from master only CVE + bug fixes. thus allow users to adopt new feature even on minor released, and adapt smoothly to breaking change on major release. (this imply to distinguish between *new feature* and *breaking changes* ?) Best regards, Christophe. Le lun. 17 juil. 2023 à 21:59, Ryan Skraba a écrit : > Hello! There's a number of outstanding questions and discussions > about releases, maintenance, lifecycle :D I thought it might be > productive to make a goal to work towards. > > Specifically, I couldn't point to a policy about this question being > asked on the user@ mailing list: when do we stop maintaining a > version? My experience over the last few years has been that we only > have one version under development at a time. > > One of the major brakes in doing this last release was deciding what > to do with each and every commit on the master branch -- having a > concrete policy and decision on this would definitely help committers > decide when, what and where to cherry-pick changes! > > From 1.12.0 on, I'd like to propose maintaining *two* major versions > (i.e. 1.12.x and 1.11.x). That would allow us to deprecate and modify > APIs and give developers one whole major release to switch. The > "older" major version would receive *only* bug and security fixes, the > "newest" major version gets those as well as non-API breaking > features. > > All work is committed to master, and the committer makes the decision > how far to cherry-pick, or (in the absence of time) keeps the JIRA > fixVersion up-to-date for someone to pick up the intention. > > That's just one suggestion that seems plausible to me! We can > probably do better without much additional effort (on the limited > resources we have). What do you think? > > All my best regards, Ryan > > On Mon, Jul 17, 2023 at 9:43 PM Ryan Skraba wrote: > > > > Hello! While Avro doesn't have an official "end-of-life" statement or > > policy, there is no active development on the 1.9 or 1.10 branch. > > > > Our current policy is to add major features to the next major release > > (1.12.0) while bug fixes, CVEs and minor features will be backported > > to the next minor release (1.11.3). > > > > I think we *should* have a policy in place, for projects that depend > > on Avro to have a better visiblity. I will bring this up on the > > dev@avro.apache.org mailing list -- please feel free to join the > > discussion! > > > > All my best, Ryan > > > > > > On Mon, Jul 17, 2023 at 11:19 AM Pranav Kumar (EXT) via user > > wrote: > > > > > > Hi, > > > > > > > > > > > > Could you please share End of life/End of support detail or any EoS > criteria that is followed for below: > > > > > > > > > > > > Apache Avro version-1.9.2 > > > > > > > > > > > > Regards, > > > > > > Pranav >
[GitHub] [avro] clesaec opened a new pull request, #2364: AVRO-2236: [java] default value for record type
clesaec opened a new pull request, #2364: URL: https://github.com/apache/avro/pull/2364 ## What is the purpose of the change [AVRO-2236](https://issues.apache.org/jira/browse/AVRO-2236) : Add default value for record type. This PR allow a field is of type record to have a default value even if the record itself have field with other default values (with union type). ## Verifying this change - new unit test TestSchemaValidateDefault ## Documentation - Does this pull request introduce a new feature? (no) - If yes, how is the feature documented? (not applicable) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@avro.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (AVRO-3802) Memory leak on decompressing deflate codes avro files
amy myo created AVRO-3802: - Summary: Memory leak on decompressing deflate codes avro files Key: AVRO-3802 URL: https://issues.apache.org/jira/browse/AVRO-3802 Project: Apache Avro Issue Type: Bug Components: csharp Affects Versions: 1.11.2, 1.11.1, 1.12.0, 1.11.3 Reporter: amy myo -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [avro] clesaec opened a new pull request, #2365: AVRO-2254: [java] fix unresolved shema name
clesaec opened a new pull request, #2365: URL: https://github.com/apache/avro/pull/2365 ## What is the purpose of the change [AVRO-2254](https://issues.apache.org/jira/browse/AVRO-2254) : Currently, SchemaResolver.unresolvedSchema method generate always schema with same name. The idea supply Zoltan Farkas is to generate another name each time. So, the intent of this PR is just to transformed what is proposed in PR form. ## Verifying this change unio.avdl + union.avpr add test on this. ## Documentation - Does this pull request introduce a new feature? (no) - If yes, how is the feature documented? (not applicable) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@avro.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [avro] clesaec opened a new pull request, #2366: AVRO-2284: fix unit test code
clesaec opened a new pull request, #2366: URL: https://github.com/apache/avro/pull/2366 ## What is the purpose of the change [AVRO-2284](https://issues.apache.org/jira/browse/AVRO-2284) : fix unit test ## Verifying this change just run unit test ## Documentation - Does this pull request introduce a new feature? (no) - If yes, how is the feature documented? (not applicable) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@avro.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [DISCUSS] Release maintenance and lifecycle
I like Christophe's proposal ! On Tue, Jul 18, 2023 at 11:52 AM Christophe Le Saëc wrote: > Hello > I find this proposal relevant. > > to clarify : > > > From 1.12.0 on, I'd like to propose maintaining *two* major versions > > (i.e. 1.12.x and 1.11.x). That would allow us to deprecate and modify > > APIs and give developers one whole major release to switch. > > this means to maintain 3 branches (1.13.0-SNAPSHOT (master), 1.12.x and > 1.11.x) ? > > what about ? > - master (1.13.0-SNAPSHOT) receive new feature + CVE + bug fixes + API > breaking change (keeping old API with deprecated tag when possible) and > remove old deprecated API (possibly not compatible with 1.12.x) > - 1.12.x receive from master new feature + CVE + bug fixes (1.12.n+1 should > stay compatible with 1.12.n, so, it won't receive breaking change). > - 1.11.x receive from master only CVE + bug fixes. > > thus allow users to adopt new feature even on minor released, and adapt > smoothly to breaking change on major release. > (this imply to distinguish between *new feature* and *breaking changes* ?) > > Best regards, > Christophe. > > > Le lun. 17 juil. 2023 à 21:59, Ryan Skraba a écrit : > > > Hello! There's a number of outstanding questions and discussions > > about releases, maintenance, lifecycle :D I thought it might be > > productive to make a goal to work towards. > > > > Specifically, I couldn't point to a policy about this question being > > asked on the user@ mailing list: when do we stop maintaining a > > version? My experience over the last few years has been that we only > > have one version under development at a time. > > > > One of the major brakes in doing this last release was deciding what > > to do with each and every commit on the master branch -- having a > > concrete policy and decision on this would definitely help committers > > decide when, what and where to cherry-pick changes! > > > > From 1.12.0 on, I'd like to propose maintaining *two* major versions > > (i.e. 1.12.x and 1.11.x). That would allow us to deprecate and modify > > APIs and give developers one whole major release to switch. The > > "older" major version would receive *only* bug and security fixes, the > > "newest" major version gets those as well as non-API breaking > > features. > > > > All work is committed to master, and the committer makes the decision > > how far to cherry-pick, or (in the absence of time) keeps the JIRA > > fixVersion up-to-date for someone to pick up the intention. > > > > That's just one suggestion that seems plausible to me! We can > > probably do better without much additional effort (on the limited > > resources we have). What do you think? > > > > All my best regards, Ryan > > > > On Mon, Jul 17, 2023 at 9:43 PM Ryan Skraba wrote: > > > > > > Hello! While Avro doesn't have an official "end-of-life" statement or > > > policy, there is no active development on the 1.9 or 1.10 branch. > > > > > > Our current policy is to add major features to the next major release > > > (1.12.0) while bug fixes, CVEs and minor features will be backported > > > to the next minor release (1.11.3). > > > > > > I think we *should* have a policy in place, for projects that depend > > > on Avro to have a better visiblity. I will bring this up on the > > > dev@avro.apache.org mailing list -- please feel free to join the > > > discussion! > > > > > > All my best, Ryan > > > > > > > > > On Mon, Jul 17, 2023 at 11:19 AM Pranav Kumar (EXT) via user > > > wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > Could you please share End of life/End of support detail or any EoS > > criteria that is followed for below: > > > > > > > > > > > > > > > > Apache Avro version-1.9.2 > > > > > > > > > > > > > > > > Regards, > > > > > > > > Pranav > > >
[GitHub] [avro] kojiromike opened a new pull request, #2367: AVRO-1737 Test that Schema are Hashable
kojiromike opened a new pull request, #2367: URL: https://github.com/apache/avro/pull/2367 This test should fail right now. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@avro.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (AVRO-3803) Fix avro.ipc bugs
Michael A. Smith created AVRO-3803:
--
Summary: Fix avro.ipc bugs
Key: AVRO-3803
URL: https://issues.apache.org/jira/browse/AVRO-3803
Project: Apache Avro
Issue Type: Bug
Components: python
Affects Versions: 1.11.2
Reporter: Michael A. Smith
There are several issues with avro.ipc
* FramedReader results in an infinite loop where it cannot read anything from
the response. (It compares bytes to a string).
* Error handling for the Responder:
** Invalid error source: {{except}} was pointing at {{schema.AvroException}}
instead of {{avro.errors.AvroException}}
** "Handshake" was lost for cases where the response could not be read due to
things like "type errors"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
