You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avro.apache.org by Martin Grigorov <mg...@apache.org> on 2023/01/03 14:01:50 UTC
Release language modules separately
Happy new year Avro community!
I wish you to have a lot of fun while developing your projects!
I'd like to propose to make it possible to release a single module/lang.
At the moment all modules share the same version and are being released
together.
The problem is that the release cadence is rather slow and some users
complain about it, e.g. the C# and Rust ones.
The only "problem" I see is that the modules will have different versions
from now on, e.g. Java will be 1.11.1 and the C# module will be 1.12.0.
(The Rust one is still at 0.15.0 :-) ).
This might confuse some users but we just have to make it clear in the docs
that the important number is the Avro spec version, i.e. "1". The modules
do not implement the whole set of features
even now.
As of now, a release of a single module (or a sub-set of modules) will
require the same ASF release rules (3 binding +1s, at least 72 hours for
voting, etc.).
What do you think ?
Regards,
Martin
Re: Release language modules separately
Posted by Christophe Le Saëc <ch...@gmail.com>.
👍
Le jeu. 5 janv. 2023 à 13:58, Martin Grigorov <mg...@apache.org> a
écrit :
> Hi,
>
> On Thu, Jan 5, 2023 at 2:40 PM Christophe Le Saëc <ch...@gmail.com>
> wrote:
>
> > I'm also in favor of this idea (+1).
> > Just to figure out,*splitting the language SDKs to separate releases and
> > releasing separately.* : Concretely, is this means that there will be one
> > github repo for each language (So 10 avro github repo); or is there any
> > other "github" trick to manage separate release in same repo ?
> >
>
> Github is not related.
> Currently the release manager (Ryan) uses shell script(s) to release all
> SDKs.
> If the proposed idea is approved then the release manager (any PMC member)
> will execute just the script(s) for the released SDK(s).
> Currently the release scripts use share/VERSION.txt as a shared resource.
> This will have to be re-thinked.
>
>
> >
> > Le mer. 4 janv. 2023 à 20:58, Martin Grigorov <mg...@apache.org> a
> > écrit :
> >
> > > Thanks, Ryan!
> > >
> > > I have forgotten about the previous discussion!
> > >
> > > On Wed, Jan 4, 2023 at 8:15 PM Ryan Skraba <ry...@skraba.com> wrote:
> > >
> > > > Hello! We've started and stopped this discussion a couple of times
> --
> > > > but it ends up getting a bit bogged down in details, and there's so
> > > > much going on that we end on sticking with the status quo!
> > > >
> > > > I would love to have this discussion again though and come to a
> > > > conclusion. We could be doing quite a few things better, and
> changing
> > > > our release strategy to a more flexible and modern style is likely
> > > > going to make things easier for us in the long run.
> > > >
> > > > Among the related topics are:
> > > >
> > > > 1) Moving to more recognizable semantic versioning (i.e., dropping
> the
> > > > "1." prefix in Avro).
> > > >
> > >
> > > I am +1 for this!
> > >
> > >
> > > > 2) Versioning the website and specification for releases.
> > > >
> > >
> > > This is discussed at
> > > https://lists.apache.org/thread/29mzv23z3940sxmchj7c7s9ozq0fb874
> > > But with the idea of splitting the SDKs releases it becomes harder to
> say
> > > how exactly to version the documentation.
> > >
> > >
> > > > 3) Supporting N minor releases simultaneously (where N is more than
> 1)
> > > >
> > >
> > > I still think that 2 major releases is the best we could do with the
> > > current number of active developers.
> > >
> > >
> > > > 4) Splitting the language SDKs to separate releases and releasing
> > > > separately.
> > > >
> > >
> > > +1
> > >
> > >
> > > >
> > > > Just for reference, I always like to link the thread to the last time
> > > > we discussed (which links to the previous years). There's quite a few
> > > > good points! I don't think we can ever really satisfy everyone, but
> > > > we can definitely make changes.
> > >
> > >
> > > > Maybe a good way to get to consensus would be to list the possible
> > > > actions we could take, and prioritize them?
> > > >
> > >
> > > Shall we have an official VOTE for those ?
> > >
> > >
> > > >
> > > > Thanks for bringing this up and HAPPY NEW YEAR everybody!
> > > >
> > > > Ryan
> > > >
> > > > [1]:
> https://lists.apache.org/thread/rybf7vb514mtkr7swfld7b06g1kb2r3t
> > > > "[DISCUSS] Releases, versioning and lifecycle"
> > > >
> > > >
> > > > On Wed, Jan 4, 2023 at 1:05 PM Oscar Westra van Holthe - Kind
> > > > <os...@westravanholthe.nl> wrote:
> > > > >
> > > > > On Wed, 4 Jan 2023 at 08:15, Martin Grigorov <mgrigorov@apache.org
> >
> > > > wrote:
> > > > > > [...] the problem is the availability of active maintainers.
> > > > >
> > > > > This is another issue, and important too IMHO. I'm just not certain
> > > > there's
> > > > > a solution though.
> > > > > I'll raise another thread if I ever have ideas to tackle it.
> > > > >
> > > > > Kind regards,
> > > > > Oscar
> > > > >
> > > > > --
> > > > >
> > > > > ✉️ Oscar Westra van Holthe - Kind <os...@westravanholthe.nl>
> > > >
> > >
> >
>
Re: Release language modules separately
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Thu, Jan 5, 2023 at 2:40 PM Christophe Le Saëc <ch...@gmail.com>
wrote:
> I'm also in favor of this idea (+1).
> Just to figure out,*splitting the language SDKs to separate releases and
> releasing separately.* : Concretely, is this means that there will be one
> github repo for each language (So 10 avro github repo); or is there any
> other "github" trick to manage separate release in same repo ?
>
Github is not related.
Currently the release manager (Ryan) uses shell script(s) to release all
SDKs.
If the proposed idea is approved then the release manager (any PMC member)
will execute just the script(s) for the released SDK(s).
Currently the release scripts use share/VERSION.txt as a shared resource.
This will have to be re-thinked.
>
> Le mer. 4 janv. 2023 à 20:58, Martin Grigorov <mg...@apache.org> a
> écrit :
>
> > Thanks, Ryan!
> >
> > I have forgotten about the previous discussion!
> >
> > On Wed, Jan 4, 2023 at 8:15 PM Ryan Skraba <ry...@skraba.com> wrote:
> >
> > > Hello! We've started and stopped this discussion a couple of times --
> > > but it ends up getting a bit bogged down in details, and there's so
> > > much going on that we end on sticking with the status quo!
> > >
> > > I would love to have this discussion again though and come to a
> > > conclusion. We could be doing quite a few things better, and changing
> > > our release strategy to a more flexible and modern style is likely
> > > going to make things easier for us in the long run.
> > >
> > > Among the related topics are:
> > >
> > > 1) Moving to more recognizable semantic versioning (i.e., dropping the
> > > "1." prefix in Avro).
> > >
> >
> > I am +1 for this!
> >
> >
> > > 2) Versioning the website and specification for releases.
> > >
> >
> > This is discussed at
> > https://lists.apache.org/thread/29mzv23z3940sxmchj7c7s9ozq0fb874
> > But with the idea of splitting the SDKs releases it becomes harder to say
> > how exactly to version the documentation.
> >
> >
> > > 3) Supporting N minor releases simultaneously (where N is more than 1)
> > >
> >
> > I still think that 2 major releases is the best we could do with the
> > current number of active developers.
> >
> >
> > > 4) Splitting the language SDKs to separate releases and releasing
> > > separately.
> > >
> >
> > +1
> >
> >
> > >
> > > Just for reference, I always like to link the thread to the last time
> > > we discussed (which links to the previous years). There's quite a few
> > > good points! I don't think we can ever really satisfy everyone, but
> > > we can definitely make changes.
> >
> >
> > > Maybe a good way to get to consensus would be to list the possible
> > > actions we could take, and prioritize them?
> > >
> >
> > Shall we have an official VOTE for those ?
> >
> >
> > >
> > > Thanks for bringing this up and HAPPY NEW YEAR everybody!
> > >
> > > Ryan
> > >
> > > [1]: https://lists.apache.org/thread/rybf7vb514mtkr7swfld7b06g1kb2r3t
> > > "[DISCUSS] Releases, versioning and lifecycle"
> > >
> > >
> > > On Wed, Jan 4, 2023 at 1:05 PM Oscar Westra van Holthe - Kind
> > > <os...@westravanholthe.nl> wrote:
> > > >
> > > > On Wed, 4 Jan 2023 at 08:15, Martin Grigorov <mg...@apache.org>
> > > wrote:
> > > > > [...] the problem is the availability of active maintainers.
> > > >
> > > > This is another issue, and important too IMHO. I'm just not certain
> > > there's
> > > > a solution though.
> > > > I'll raise another thread if I ever have ideas to tackle it.
> > > >
> > > > Kind regards,
> > > > Oscar
> > > >
> > > > --
> > > >
> > > > ✉️ Oscar Westra van Holthe - Kind <os...@westravanholthe.nl>
> > >
> >
>
Re: Release language modules separately
Posted by Christophe Le Saëc <ch...@gmail.com>.
I'm also in favor of this idea (+1).
Just to figure out,*splitting the language SDKs to separate releases and
releasing separately.* : Concretely, is this means that there will be one
github repo for each language (So 10 avro github repo); or is there any
other "github" trick to manage separate release in same repo ?
Le mer. 4 janv. 2023 à 20:58, Martin Grigorov <mg...@apache.org> a
écrit :
> Thanks, Ryan!
>
> I have forgotten about the previous discussion!
>
> On Wed, Jan 4, 2023 at 8:15 PM Ryan Skraba <ry...@skraba.com> wrote:
>
> > Hello! We've started and stopped this discussion a couple of times --
> > but it ends up getting a bit bogged down in details, and there's so
> > much going on that we end on sticking with the status quo!
> >
> > I would love to have this discussion again though and come to a
> > conclusion. We could be doing quite a few things better, and changing
> > our release strategy to a more flexible and modern style is likely
> > going to make things easier for us in the long run.
> >
> > Among the related topics are:
> >
> > 1) Moving to more recognizable semantic versioning (i.e., dropping the
> > "1." prefix in Avro).
> >
>
> I am +1 for this!
>
>
> > 2) Versioning the website and specification for releases.
> >
>
> This is discussed at
> https://lists.apache.org/thread/29mzv23z3940sxmchj7c7s9ozq0fb874
> But with the idea of splitting the SDKs releases it becomes harder to say
> how exactly to version the documentation.
>
>
> > 3) Supporting N minor releases simultaneously (where N is more than 1)
> >
>
> I still think that 2 major releases is the best we could do with the
> current number of active developers.
>
>
> > 4) Splitting the language SDKs to separate releases and releasing
> > separately.
> >
>
> +1
>
>
> >
> > Just for reference, I always like to link the thread to the last time
> > we discussed (which links to the previous years). There's quite a few
> > good points! I don't think we can ever really satisfy everyone, but
> > we can definitely make changes.
>
>
> > Maybe a good way to get to consensus would be to list the possible
> > actions we could take, and prioritize them?
> >
>
> Shall we have an official VOTE for those ?
>
>
> >
> > Thanks for bringing this up and HAPPY NEW YEAR everybody!
> >
> > Ryan
> >
> > [1]: https://lists.apache.org/thread/rybf7vb514mtkr7swfld7b06g1kb2r3t
> > "[DISCUSS] Releases, versioning and lifecycle"
> >
> >
> > On Wed, Jan 4, 2023 at 1:05 PM Oscar Westra van Holthe - Kind
> > <os...@westravanholthe.nl> wrote:
> > >
> > > On Wed, 4 Jan 2023 at 08:15, Martin Grigorov <mg...@apache.org>
> > wrote:
> > > > [...] the problem is the availability of active maintainers.
> > >
> > > This is another issue, and important too IMHO. I'm just not certain
> > there's
> > > a solution though.
> > > I'll raise another thread if I ever have ideas to tackle it.
> > >
> > > Kind regards,
> > > Oscar
> > >
> > > --
> > >
> > > ✉️ Oscar Westra van Holthe - Kind <os...@westravanholthe.nl>
> >
>
Re: Release language modules separately
Posted by Martin Grigorov <mg...@apache.org>.
Thanks, Ryan!
I have forgotten about the previous discussion!
On Wed, Jan 4, 2023 at 8:15 PM Ryan Skraba <ry...@skraba.com> wrote:
> Hello! We've started and stopped this discussion a couple of times --
> but it ends up getting a bit bogged down in details, and there's so
> much going on that we end on sticking with the status quo!
>
> I would love to have this discussion again though and come to a
> conclusion. We could be doing quite a few things better, and changing
> our release strategy to a more flexible and modern style is likely
> going to make things easier for us in the long run.
>
> Among the related topics are:
>
> 1) Moving to more recognizable semantic versioning (i.e., dropping the
> "1." prefix in Avro).
>
I am +1 for this!
> 2) Versioning the website and specification for releases.
>
This is discussed at
https://lists.apache.org/thread/29mzv23z3940sxmchj7c7s9ozq0fb874
But with the idea of splitting the SDKs releases it becomes harder to say
how exactly to version the documentation.
> 3) Supporting N minor releases simultaneously (where N is more than 1)
>
I still think that 2 major releases is the best we could do with the
current number of active developers.
> 4) Splitting the language SDKs to separate releases and releasing
> separately.
>
+1
>
> Just for reference, I always like to link the thread to the last time
> we discussed (which links to the previous years). There's quite a few
> good points! I don't think we can ever really satisfy everyone, but
> we can definitely make changes.
> Maybe a good way to get to consensus would be to list the possible
> actions we could take, and prioritize them?
>
Shall we have an official VOTE for those ?
>
> Thanks for bringing this up and HAPPY NEW YEAR everybody!
>
> Ryan
>
> [1]: https://lists.apache.org/thread/rybf7vb514mtkr7swfld7b06g1kb2r3t
> "[DISCUSS] Releases, versioning and lifecycle"
>
>
> On Wed, Jan 4, 2023 at 1:05 PM Oscar Westra van Holthe - Kind
> <os...@westravanholthe.nl> wrote:
> >
> > On Wed, 4 Jan 2023 at 08:15, Martin Grigorov <mg...@apache.org>
> wrote:
> > > [...] the problem is the availability of active maintainers.
> >
> > This is another issue, and important too IMHO. I'm just not certain
> there's
> > a solution though.
> > I'll raise another thread if I ever have ideas to tackle it.
> >
> > Kind regards,
> > Oscar
> >
> > --
> >
> > ✉️ Oscar Westra van Holthe - Kind <os...@westravanholthe.nl>
>
Re: Release language modules separately
Posted by Oscar Westra van Holthe - Kind <os...@westravanholthe.nl>.
For ease of maintenance, I think we should follow these rules:
- one (mono)repo
- each SDK has one stable version: main/master, that's available to be
released on short notice
- upon release, all changed SDKs get a new, appropriate, semantic version
- all current SDK versions must be compatible with whatever is in the
shared / documentation / ... folders
The only 'downside' is that these rules require proper pull request
handling (only merge stuff that's stable/tested), but our track record on
that is excellent.
The idea to build a "this SDK supports these features" table is then one to
pick up quickly after we implement our choice.
Anyway, that's my opinion on the matter.
Kind regards,
Oscar
--
Oscar Westra van Holthe - Kind <os...@westravanholthe.nl>
Op vr 13 jan. 2023 09:31 schreef Christophe Le Saëc <ch...@gmail.com>:
> Indeed, "Commons tests" embeds avro files that aims to be used in tests for
> every SDKs, but we also can add meta information to minimum SDK version is
> required for this tests.
> Concretely, with this files <
> https://github.com/apache/avro/pull/1850/files>,
> adding "meta.properties" on each share/test/data/schemas/ subfolder that
> would contains "sdk.version.min=12" ... So, each SDK would automatically
> select files that it have to test.
> And finally, there may have no real issue with other "share" file (i see
> lot of them not modified since many years on github)
>
> Le jeu. 12 janv. 2023 à 17:53, Martin Grigorov <mg...@apache.org> a
> écrit :
>
> > On Thu, Jan 12, 2023, 17:33 Christophe Le Saëc <ch...@gmail.com>
> wrote:
> >
> > > So, if i take the latest one; i could have
> > > lang/java 13.1
> > > lang/python 11.2
> > > lang/rust 12.3
> > >
> > > So what will contains *share* folder if it should integrates some
> updates
> > > between 11 & 12 and between 12 & 13 ? (some sub-folder share/11 ... ?
> to
> > > allow lang/java to use share/13, lang/python to use share/11 ... ?
> > >
> >
> > Do you mean "to support changes in different versions of the
> specification"
> > or in the common tests?
> >
> > I see the common tests as something that any SDK can decide to implement
> a
> > specific test at any time no matter what is the SDK's version.
> >
> >
> > > Le jeu. 12 janv. 2023 à 15:19, Martin Grigorov <mg...@apache.org>
> a
> > > écrit :
> > >
> > > > On Thu, Jan 12, 2023 at 3:12 PM Christophe Le Saëc <
> chlesaec@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > With one github repo; how to manage share
> > > > > <https://github.com/apache/avro/tree/master/share> folder ? i mean
> > if
> > > > one
> > > > > version need updates on this repo but not the older.
> > > > >
> > > > > As an example, this JIRA AVRO-3591
> > > > > <https://issues.apache.org/jira/browse/AVRO-3591> aims to create
> > > commons
> > > > > inter sdk unit tests (The PR <
> > https://github.com/apache/avro/pull/1850
> > > >
> > > > > add
> > > > > some files on share folder); commons tests could be valid for a
> > version
> > > > but
> > > > > not for an older one.
> > > > >
> > > >
> > > > I don't see the problem.
> > > > The main branch in the monorepo will consists of SDKs with various
> > > > versions, but each SDK will have just one version at any time.
> > > > Older versions will be in the release tags.
> > > >
> > > >
> > > > >
> > > > >
> > > > > Le jeu. 12 janv. 2023 à 12:24, Martin Grigorov <
> mgrigorov@apache.org
> > >
> > > a
> > > > > écrit :
> > > > >
> > > > > > On Wed, Jan 11, 2023 at 9:27 PM Ryan Skraba <ry...@skraba.com>
> > wrote:
> > > > > >
> > > > > > > Hey -- how does this sound for rolling out this strategy.
> > > > > > >
> > > > > > > 1) No changes to 1.11 branch. We can release 1.11.2 to bring
> > some
> > > of
> > > > > > > the immediate bug and security fixes.
> > > > > > >
> > > > > > > 2) The next major release of Avro will be 12.0.0 for the
> > > > specification
> > > > > > > and all SDK (except maybe Rust) and we'll start following
> > semantic
> > > > > > > versioning per-SDK, with "traditional" major.minor.patch
> > versions.
> > > > > > >
> > > > > > > 2b) The specification (and probably some other documentation)
> now
> > > has
> > > > > > > a version separate from the SDKs, and it'll probably stay at
> 12.x
> > > > > > > forever as long as we call this project Avro (no breaking
> > changes).
> > > > I
> > > > > > > agree it would be great to have a "compliance" matrix on the
> > > website!
> > > > > > >
> > > > > > > 2c) We can expect more active/experimental SDKs to go to 13.x,
> > 14.x
> > > > > > > when breaking changes are introduced, while stable and less
> > active
> > > > > > > SDKs to go to 12.1.x, 12.2.x ... That's fine and that's life if
> > the
> > > > > > > major version isn't the same for SDKs -- bumping the major
> > version
> > > > > > > doesn't mean "better". We can decide whether this is working
> for
> > > us
> > > > > > > during 12.x, and figure out how to address interoperability
> > > questions
> > > > > > > (between versions and between SDKs).
> > > > > > >
> > > > > > > 3) We'll have to figure out a navigation system per SDK for the
> > > > > > > website, but we'll have a bit of time to do that. Hopefully it
> > > > > > > doesn't break Martin's current investigation with branch
> release
> > > > > > > artifacts.
> > > > > > >
> > > > > > > 4) We can decide how many major versions remain supported
> > per-sdk.
> > > > > > >
> > > > > > > In my opinion, the "semantic versioning" VOTE is a
> pre-requisite
> > to
> > > > > > > the SDK/splitting vote -- currently I'd be confused if I saw a
> > 1.12
> > > > > > > Avro python SDK available, but not a Java one. The big change
> to
> > > > 12.x
> > > > > > > makes this a bit more obvious (and is also something devs have
> > been
> > > > > > > asking for since I've been with the project!)
> > > > > > >
> > > > > > > Another thing I'd like to talk about before calling a VOTE is
> > > github
> > > > > > > branches... I've been trying to wrap my head around it, but
> it's
> > > > still
> > > > > > > a bit unclear to me how we should manage this in a mono-repo.
> > > > > > >
> > > > > >
> > > > > > This is exactly what stopped me proceeding with the vote!
> > > > > >
> > > > > > One option is to split the monorepo to repo-per-sdk but this is a
> > big
> > > > > task!
> > > > > >
> > > > > > The other viable option I see is to have just one branch (master)
> > > where
> > > > > all
> > > > > > SDKs evolve in their own pace and bump their versions as they
> need.
> > > > > > When a user asks for a maintaince release then a developer could
> > > > create a
> > > > > > branch from an earlier commit (e.g. from the respective
> > tag/release)
> > > > and
> > > > > > apply the requested bug fixes. From my experience so far there
> were
> > > not
> > > > > > many such requests.
> > > > > > Such maintanance branches should be short lived - only for the
> > > > requested
> > > > > > big fix! Once a new release is tagged, e.g. release-rust-12.1.1,
> > then
> > > > the
> > > > > > branch should be removed to avoid any confusions. Also such
> > branches
> > > > > should
> > > > > > be used only for the release of one SDK!
> > > > > >
> > > > > > I stopped working on the PR for the asf.yaml based website
> because
> > I
> > > > > > honestly have no idea how to support the split documentations per
> > SDK
> > > > per
> > > > > > version in a monorepo...
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > In any case, I'm motivated to keep this discussion going! :D
> > I'd
> > > > > > > definitely vote +1 on the "should we?" but "and how?" could
> use a
> > > bit
> > > > > > > of refinement.
> > > > > > >
> > > > > > > All my best, Ryan
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Jan 11, 2023 at 10:12 AM Khrystyna Popadyuk
> > > > > > > <kh...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > +1 for separating out the releasesе too
> > > > > > > >
> > > > > > > > On Sat, Jan 7, 2023 at 4:46 AM Ryan Blue <bl...@tabular.io>
> > > wrote:
> > > > > > > >
> > > > > > > > > +1 for separating out the releases and starting a vote on
> > just
> > > > > that.
> > > > > > > We can
> > > > > > > > > debate the other details as we go.
> > > > > > > > >
> > > > > > > > > On Thu, Jan 5, 2023 at 12:25 PM Tim Perkins <
> > > > tjwperkins@gmail.com>
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > On Wed, Jan 4, 2023 at 1:15 PM Ryan Skraba <
> > ryan@skraba.com>
> > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Maybe a good way to get to consensus would be to list
> the
> > > > > > possible
> > > > > > > > > > > actions we could take, and prioritize them?
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > One of the actions that I would like to see is the
> > > compilation
> > > > of
> > > > > > > which
> > > > > > > > > > parts of the spec each language implements. This would
> be a
> > > > > useful
> > > > > > > > > addition
> > > > > > > > > > to the documentation.
> > > > > > > > > >
> > > > > > > > > > If we compile this table it may be that it requires a lot
> > of
> > > > > > > footnotes
> > > > > > > > > and
> > > > > > > > > > qualifications for differences in how languages implement
> > the
> > > > > spec,
> > > > > > > but
> > > > > > > > > > overall it would still be useful to identify gaps,
> > highlight
> > > > > > > differences,
> > > > > > > > > > and perhaps ultimately drive more compatibility.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Ryan Blue
> > > > > > > > > Tabular
> > > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Release language modules separately
Posted by Christophe Le Saëc <ch...@gmail.com>.
Indeed, "Commons tests" embeds avro files that aims to be used in tests for
every SDKs, but we also can add meta information to minimum SDK version is
required for this tests.
Concretely, with this files <https://github.com/apache/avro/pull/1850/files>,
adding "meta.properties" on each share/test/data/schemas/ subfolder that
would contains "sdk.version.min=12" ... So, each SDK would automatically
select files that it have to test.
And finally, there may have no real issue with other "share" file (i see
lot of them not modified since many years on github)
Le jeu. 12 janv. 2023 à 17:53, Martin Grigorov <mg...@apache.org> a
écrit :
> On Thu, Jan 12, 2023, 17:33 Christophe Le Saëc <ch...@gmail.com> wrote:
>
> > So, if i take the latest one; i could have
> > lang/java 13.1
> > lang/python 11.2
> > lang/rust 12.3
> >
> > So what will contains *share* folder if it should integrates some updates
> > between 11 & 12 and between 12 & 13 ? (some sub-folder share/11 ... ? to
> > allow lang/java to use share/13, lang/python to use share/11 ... ?
> >
>
> Do you mean "to support changes in different versions of the specification"
> or in the common tests?
>
> I see the common tests as something that any SDK can decide to implement a
> specific test at any time no matter what is the SDK's version.
>
>
> > Le jeu. 12 janv. 2023 à 15:19, Martin Grigorov <mg...@apache.org> a
> > écrit :
> >
> > > On Thu, Jan 12, 2023 at 3:12 PM Christophe Le Saëc <chlesaec@gmail.com
> >
> > > wrote:
> > >
> > > > With one github repo; how to manage share
> > > > <https://github.com/apache/avro/tree/master/share> folder ? i mean
> if
> > > one
> > > > version need updates on this repo but not the older.
> > > >
> > > > As an example, this JIRA AVRO-3591
> > > > <https://issues.apache.org/jira/browse/AVRO-3591> aims to create
> > commons
> > > > inter sdk unit tests (The PR <
> https://github.com/apache/avro/pull/1850
> > >
> > > > add
> > > > some files on share folder); commons tests could be valid for a
> version
> > > but
> > > > not for an older one.
> > > >
> > >
> > > I don't see the problem.
> > > The main branch in the monorepo will consists of SDKs with various
> > > versions, but each SDK will have just one version at any time.
> > > Older versions will be in the release tags.
> > >
> > >
> > > >
> > > >
> > > > Le jeu. 12 janv. 2023 à 12:24, Martin Grigorov <mgrigorov@apache.org
> >
> > a
> > > > écrit :
> > > >
> > > > > On Wed, Jan 11, 2023 at 9:27 PM Ryan Skraba <ry...@skraba.com>
> wrote:
> > > > >
> > > > > > Hey -- how does this sound for rolling out this strategy.
> > > > > >
> > > > > > 1) No changes to 1.11 branch. We can release 1.11.2 to bring
> some
> > of
> > > > > > the immediate bug and security fixes.
> > > > > >
> > > > > > 2) The next major release of Avro will be 12.0.0 for the
> > > specification
> > > > > > and all SDK (except maybe Rust) and we'll start following
> semantic
> > > > > > versioning per-SDK, with "traditional" major.minor.patch
> versions.
> > > > > >
> > > > > > 2b) The specification (and probably some other documentation) now
> > has
> > > > > > a version separate from the SDKs, and it'll probably stay at 12.x
> > > > > > forever as long as we call this project Avro (no breaking
> changes).
> > > I
> > > > > > agree it would be great to have a "compliance" matrix on the
> > website!
> > > > > >
> > > > > > 2c) We can expect more active/experimental SDKs to go to 13.x,
> 14.x
> > > > > > when breaking changes are introduced, while stable and less
> active
> > > > > > SDKs to go to 12.1.x, 12.2.x ... That's fine and that's life if
> the
> > > > > > major version isn't the same for SDKs -- bumping the major
> version
> > > > > > doesn't mean "better". We can decide whether this is working for
> > us
> > > > > > during 12.x, and figure out how to address interoperability
> > questions
> > > > > > (between versions and between SDKs).
> > > > > >
> > > > > > 3) We'll have to figure out a navigation system per SDK for the
> > > > > > website, but we'll have a bit of time to do that. Hopefully it
> > > > > > doesn't break Martin's current investigation with branch release
> > > > > > artifacts.
> > > > > >
> > > > > > 4) We can decide how many major versions remain supported
> per-sdk.
> > > > > >
> > > > > > In my opinion, the "semantic versioning" VOTE is a pre-requisite
> to
> > > > > > the SDK/splitting vote -- currently I'd be confused if I saw a
> 1.12
> > > > > > Avro python SDK available, but not a Java one. The big change to
> > > 12.x
> > > > > > makes this a bit more obvious (and is also something devs have
> been
> > > > > > asking for since I've been with the project!)
> > > > > >
> > > > > > Another thing I'd like to talk about before calling a VOTE is
> > github
> > > > > > branches... I've been trying to wrap my head around it, but it's
> > > still
> > > > > > a bit unclear to me how we should manage this in a mono-repo.
> > > > > >
> > > > >
> > > > > This is exactly what stopped me proceeding with the vote!
> > > > >
> > > > > One option is to split the monorepo to repo-per-sdk but this is a
> big
> > > > task!
> > > > >
> > > > > The other viable option I see is to have just one branch (master)
> > where
> > > > all
> > > > > SDKs evolve in their own pace and bump their versions as they need.
> > > > > When a user asks for a maintaince release then a developer could
> > > create a
> > > > > branch from an earlier commit (e.g. from the respective
> tag/release)
> > > and
> > > > > apply the requested bug fixes. From my experience so far there were
> > not
> > > > > many such requests.
> > > > > Such maintanance branches should be short lived - only for the
> > > requested
> > > > > big fix! Once a new release is tagged, e.g. release-rust-12.1.1,
> then
> > > the
> > > > > branch should be removed to avoid any confusions. Also such
> branches
> > > > should
> > > > > be used only for the release of one SDK!
> > > > >
> > > > > I stopped working on the PR for the asf.yaml based website because
> I
> > > > > honestly have no idea how to support the split documentations per
> SDK
> > > per
> > > > > version in a monorepo...
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > > In any case, I'm motivated to keep this discussion going! :D
> I'd
> > > > > > definitely vote +1 on the "should we?" but "and how?" could use a
> > bit
> > > > > > of refinement.
> > > > > >
> > > > > > All my best, Ryan
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, Jan 11, 2023 at 10:12 AM Khrystyna Popadyuk
> > > > > > <kh...@gmail.com> wrote:
> > > > > > >
> > > > > > > +1 for separating out the releasesе too
> > > > > > >
> > > > > > > On Sat, Jan 7, 2023 at 4:46 AM Ryan Blue <bl...@tabular.io>
> > wrote:
> > > > > > >
> > > > > > > > +1 for separating out the releases and starting a vote on
> just
> > > > that.
> > > > > > We can
> > > > > > > > debate the other details as we go.
> > > > > > > >
> > > > > > > > On Thu, Jan 5, 2023 at 12:25 PM Tim Perkins <
> > > tjwperkins@gmail.com>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > On Wed, Jan 4, 2023 at 1:15 PM Ryan Skraba <
> ryan@skraba.com>
> > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Maybe a good way to get to consensus would be to list the
> > > > > possible
> > > > > > > > > > actions we could take, and prioritize them?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > One of the actions that I would like to see is the
> > compilation
> > > of
> > > > > > which
> > > > > > > > > parts of the spec each language implements. This would be a
> > > > useful
> > > > > > > > addition
> > > > > > > > > to the documentation.
> > > > > > > > >
> > > > > > > > > If we compile this table it may be that it requires a lot
> of
> > > > > > footnotes
> > > > > > > > and
> > > > > > > > > qualifications for differences in how languages implement
> the
> > > > spec,
> > > > > > but
> > > > > > > > > overall it would still be useful to identify gaps,
> highlight
> > > > > > differences,
> > > > > > > > > and perhaps ultimately drive more compatibility.
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Ryan Blue
> > > > > > > > Tabular
> > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Release language modules separately
Posted by Martin Grigorov <mg...@apache.org>.
On Thu, Jan 12, 2023, 17:33 Christophe Le Saëc <ch...@gmail.com> wrote:
> So, if i take the latest one; i could have
> lang/java 13.1
> lang/python 11.2
> lang/rust 12.3
>
> So what will contains *share* folder if it should integrates some updates
> between 11 & 12 and between 12 & 13 ? (some sub-folder share/11 ... ? to
> allow lang/java to use share/13, lang/python to use share/11 ... ?
>
Do you mean "to support changes in different versions of the specification"
or in the common tests?
I see the common tests as something that any SDK can decide to implement a
specific test at any time no matter what is the SDK's version.
> Le jeu. 12 janv. 2023 à 15:19, Martin Grigorov <mg...@apache.org> a
> écrit :
>
> > On Thu, Jan 12, 2023 at 3:12 PM Christophe Le Saëc <ch...@gmail.com>
> > wrote:
> >
> > > With one github repo; how to manage share
> > > <https://github.com/apache/avro/tree/master/share> folder ? i mean if
> > one
> > > version need updates on this repo but not the older.
> > >
> > > As an example, this JIRA AVRO-3591
> > > <https://issues.apache.org/jira/browse/AVRO-3591> aims to create
> commons
> > > inter sdk unit tests (The PR <https://github.com/apache/avro/pull/1850
> >
> > > add
> > > some files on share folder); commons tests could be valid for a version
> > but
> > > not for an older one.
> > >
> >
> > I don't see the problem.
> > The main branch in the monorepo will consists of SDKs with various
> > versions, but each SDK will have just one version at any time.
> > Older versions will be in the release tags.
> >
> >
> > >
> > >
> > > Le jeu. 12 janv. 2023 à 12:24, Martin Grigorov <mg...@apache.org>
> a
> > > écrit :
> > >
> > > > On Wed, Jan 11, 2023 at 9:27 PM Ryan Skraba <ry...@skraba.com> wrote:
> > > >
> > > > > Hey -- how does this sound for rolling out this strategy.
> > > > >
> > > > > 1) No changes to 1.11 branch. We can release 1.11.2 to bring some
> of
> > > > > the immediate bug and security fixes.
> > > > >
> > > > > 2) The next major release of Avro will be 12.0.0 for the
> > specification
> > > > > and all SDK (except maybe Rust) and we'll start following semantic
> > > > > versioning per-SDK, with "traditional" major.minor.patch versions.
> > > > >
> > > > > 2b) The specification (and probably some other documentation) now
> has
> > > > > a version separate from the SDKs, and it'll probably stay at 12.x
> > > > > forever as long as we call this project Avro (no breaking changes).
> > I
> > > > > agree it would be great to have a "compliance" matrix on the
> website!
> > > > >
> > > > > 2c) We can expect more active/experimental SDKs to go to 13.x, 14.x
> > > > > when breaking changes are introduced, while stable and less active
> > > > > SDKs to go to 12.1.x, 12.2.x ... That's fine and that's life if the
> > > > > major version isn't the same for SDKs -- bumping the major version
> > > > > doesn't mean "better". We can decide whether this is working for
> us
> > > > > during 12.x, and figure out how to address interoperability
> questions
> > > > > (between versions and between SDKs).
> > > > >
> > > > > 3) We'll have to figure out a navigation system per SDK for the
> > > > > website, but we'll have a bit of time to do that. Hopefully it
> > > > > doesn't break Martin's current investigation with branch release
> > > > > artifacts.
> > > > >
> > > > > 4) We can decide how many major versions remain supported per-sdk.
> > > > >
> > > > > In my opinion, the "semantic versioning" VOTE is a pre-requisite to
> > > > > the SDK/splitting vote -- currently I'd be confused if I saw a 1.12
> > > > > Avro python SDK available, but not a Java one. The big change to
> > 12.x
> > > > > makes this a bit more obvious (and is also something devs have been
> > > > > asking for since I've been with the project!)
> > > > >
> > > > > Another thing I'd like to talk about before calling a VOTE is
> github
> > > > > branches... I've been trying to wrap my head around it, but it's
> > still
> > > > > a bit unclear to me how we should manage this in a mono-repo.
> > > > >
> > > >
> > > > This is exactly what stopped me proceeding with the vote!
> > > >
> > > > One option is to split the monorepo to repo-per-sdk but this is a big
> > > task!
> > > >
> > > > The other viable option I see is to have just one branch (master)
> where
> > > all
> > > > SDKs evolve in their own pace and bump their versions as they need.
> > > > When a user asks for a maintaince release then a developer could
> > create a
> > > > branch from an earlier commit (e.g. from the respective tag/release)
> > and
> > > > apply the requested bug fixes. From my experience so far there were
> not
> > > > many such requests.
> > > > Such maintanance branches should be short lived - only for the
> > requested
> > > > big fix! Once a new release is tagged, e.g. release-rust-12.1.1, then
> > the
> > > > branch should be removed to avoid any confusions. Also such branches
> > > should
> > > > be used only for the release of one SDK!
> > > >
> > > > I stopped working on the PR for the asf.yaml based website because I
> > > > honestly have no idea how to support the split documentations per SDK
> > per
> > > > version in a monorepo...
> > > >
> > > >
> > > >
> > > > >
> > > > > In any case, I'm motivated to keep this discussion going! :D I'd
> > > > > definitely vote +1 on the "should we?" but "and how?" could use a
> bit
> > > > > of refinement.
> > > > >
> > > > > All my best, Ryan
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Jan 11, 2023 at 10:12 AM Khrystyna Popadyuk
> > > > > <kh...@gmail.com> wrote:
> > > > > >
> > > > > > +1 for separating out the releasesе too
> > > > > >
> > > > > > On Sat, Jan 7, 2023 at 4:46 AM Ryan Blue <bl...@tabular.io>
> wrote:
> > > > > >
> > > > > > > +1 for separating out the releases and starting a vote on just
> > > that.
> > > > > We can
> > > > > > > debate the other details as we go.
> > > > > > >
> > > > > > > On Thu, Jan 5, 2023 at 12:25 PM Tim Perkins <
> > tjwperkins@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > > > On Wed, Jan 4, 2023 at 1:15 PM Ryan Skraba <ry...@skraba.com>
> > > > wrote:
> > > > > > > >
> > > > > > > > > Maybe a good way to get to consensus would be to list the
> > > > possible
> > > > > > > > > actions we could take, and prioritize them?
> > > > > > > > >
> > > > > > > >
> > > > > > > > One of the actions that I would like to see is the
> compilation
> > of
> > > > > which
> > > > > > > > parts of the spec each language implements. This would be a
> > > useful
> > > > > > > addition
> > > > > > > > to the documentation.
> > > > > > > >
> > > > > > > > If we compile this table it may be that it requires a lot of
> > > > > footnotes
> > > > > > > and
> > > > > > > > qualifications for differences in how languages implement the
> > > spec,
> > > > > but
> > > > > > > > overall it would still be useful to identify gaps, highlight
> > > > > differences,
> > > > > > > > and perhaps ultimately drive more compatibility.
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Ryan Blue
> > > > > > > Tabular
> > > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Release language modules separately
Posted by Christophe Le Saëc <ch...@gmail.com>.
So, if i take the latest one; i could have
lang/java 13.1
lang/python 11.2
lang/rust 12.3
So what will contains *share* folder if it should integrates some updates
between 11 & 12 and between 12 & 13 ? (some sub-folder share/11 ... ? to
allow lang/java to use share/13, lang/python to use share/11 ... ?
Le jeu. 12 janv. 2023 à 15:19, Martin Grigorov <mg...@apache.org> a
écrit :
> On Thu, Jan 12, 2023 at 3:12 PM Christophe Le Saëc <ch...@gmail.com>
> wrote:
>
> > With one github repo; how to manage share
> > <https://github.com/apache/avro/tree/master/share> folder ? i mean if
> one
> > version need updates on this repo but not the older.
> >
> > As an example, this JIRA AVRO-3591
> > <https://issues.apache.org/jira/browse/AVRO-3591> aims to create commons
> > inter sdk unit tests (The PR <https://github.com/apache/avro/pull/1850>
> > add
> > some files on share folder); commons tests could be valid for a version
> but
> > not for an older one.
> >
>
> I don't see the problem.
> The main branch in the monorepo will consists of SDKs with various
> versions, but each SDK will have just one version at any time.
> Older versions will be in the release tags.
>
>
> >
> >
> > Le jeu. 12 janv. 2023 à 12:24, Martin Grigorov <mg...@apache.org> a
> > écrit :
> >
> > > On Wed, Jan 11, 2023 at 9:27 PM Ryan Skraba <ry...@skraba.com> wrote:
> > >
> > > > Hey -- how does this sound for rolling out this strategy.
> > > >
> > > > 1) No changes to 1.11 branch. We can release 1.11.2 to bring some of
> > > > the immediate bug and security fixes.
> > > >
> > > > 2) The next major release of Avro will be 12.0.0 for the
> specification
> > > > and all SDK (except maybe Rust) and we'll start following semantic
> > > > versioning per-SDK, with "traditional" major.minor.patch versions.
> > > >
> > > > 2b) The specification (and probably some other documentation) now has
> > > > a version separate from the SDKs, and it'll probably stay at 12.x
> > > > forever as long as we call this project Avro (no breaking changes).
> I
> > > > agree it would be great to have a "compliance" matrix on the website!
> > > >
> > > > 2c) We can expect more active/experimental SDKs to go to 13.x, 14.x
> > > > when breaking changes are introduced, while stable and less active
> > > > SDKs to go to 12.1.x, 12.2.x ... That's fine and that's life if the
> > > > major version isn't the same for SDKs -- bumping the major version
> > > > doesn't mean "better". We can decide whether this is working for us
> > > > during 12.x, and figure out how to address interoperability questions
> > > > (between versions and between SDKs).
> > > >
> > > > 3) We'll have to figure out a navigation system per SDK for the
> > > > website, but we'll have a bit of time to do that. Hopefully it
> > > > doesn't break Martin's current investigation with branch release
> > > > artifacts.
> > > >
> > > > 4) We can decide how many major versions remain supported per-sdk.
> > > >
> > > > In my opinion, the "semantic versioning" VOTE is a pre-requisite to
> > > > the SDK/splitting vote -- currently I'd be confused if I saw a 1.12
> > > > Avro python SDK available, but not a Java one. The big change to
> 12.x
> > > > makes this a bit more obvious (and is also something devs have been
> > > > asking for since I've been with the project!)
> > > >
> > > > Another thing I'd like to talk about before calling a VOTE is github
> > > > branches... I've been trying to wrap my head around it, but it's
> still
> > > > a bit unclear to me how we should manage this in a mono-repo.
> > > >
> > >
> > > This is exactly what stopped me proceeding with the vote!
> > >
> > > One option is to split the monorepo to repo-per-sdk but this is a big
> > task!
> > >
> > > The other viable option I see is to have just one branch (master) where
> > all
> > > SDKs evolve in their own pace and bump their versions as they need.
> > > When a user asks for a maintaince release then a developer could
> create a
> > > branch from an earlier commit (e.g. from the respective tag/release)
> and
> > > apply the requested bug fixes. From my experience so far there were not
> > > many such requests.
> > > Such maintanance branches should be short lived - only for the
> requested
> > > big fix! Once a new release is tagged, e.g. release-rust-12.1.1, then
> the
> > > branch should be removed to avoid any confusions. Also such branches
> > should
> > > be used only for the release of one SDK!
> > >
> > > I stopped working on the PR for the asf.yaml based website because I
> > > honestly have no idea how to support the split documentations per SDK
> per
> > > version in a monorepo...
> > >
> > >
> > >
> > > >
> > > > In any case, I'm motivated to keep this discussion going! :D I'd
> > > > definitely vote +1 on the "should we?" but "and how?" could use a bit
> > > > of refinement.
> > > >
> > > > All my best, Ryan
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Jan 11, 2023 at 10:12 AM Khrystyna Popadyuk
> > > > <kh...@gmail.com> wrote:
> > > > >
> > > > > +1 for separating out the releasesе too
> > > > >
> > > > > On Sat, Jan 7, 2023 at 4:46 AM Ryan Blue <bl...@tabular.io> wrote:
> > > > >
> > > > > > +1 for separating out the releases and starting a vote on just
> > that.
> > > > We can
> > > > > > debate the other details as we go.
> > > > > >
> > > > > > On Thu, Jan 5, 2023 at 12:25 PM Tim Perkins <
> tjwperkins@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > > On Wed, Jan 4, 2023 at 1:15 PM Ryan Skraba <ry...@skraba.com>
> > > wrote:
> > > > > > >
> > > > > > > > Maybe a good way to get to consensus would be to list the
> > > possible
> > > > > > > > actions we could take, and prioritize them?
> > > > > > > >
> > > > > > >
> > > > > > > One of the actions that I would like to see is the compilation
> of
> > > > which
> > > > > > > parts of the spec each language implements. This would be a
> > useful
> > > > > > addition
> > > > > > > to the documentation.
> > > > > > >
> > > > > > > If we compile this table it may be that it requires a lot of
> > > > footnotes
> > > > > > and
> > > > > > > qualifications for differences in how languages implement the
> > spec,
> > > > but
> > > > > > > overall it would still be useful to identify gaps, highlight
> > > > differences,
> > > > > > > and perhaps ultimately drive more compatibility.
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Ryan Blue
> > > > > > Tabular
> > > > > >
> > > >
> > >
> >
>
Re: Release language modules separately
Posted by Martin Grigorov <mg...@apache.org>.
On Thu, Jan 12, 2023 at 3:12 PM Christophe Le Saëc <ch...@gmail.com>
wrote:
> With one github repo; how to manage share
> <https://github.com/apache/avro/tree/master/share> folder ? i mean if one
> version need updates on this repo but not the older.
>
> As an example, this JIRA AVRO-3591
> <https://issues.apache.org/jira/browse/AVRO-3591> aims to create commons
> inter sdk unit tests (The PR <https://github.com/apache/avro/pull/1850>
> add
> some files on share folder); commons tests could be valid for a version but
> not for an older one.
>
I don't see the problem.
The main branch in the monorepo will consists of SDKs with various
versions, but each SDK will have just one version at any time.
Older versions will be in the release tags.
>
>
> Le jeu. 12 janv. 2023 à 12:24, Martin Grigorov <mg...@apache.org> a
> écrit :
>
> > On Wed, Jan 11, 2023 at 9:27 PM Ryan Skraba <ry...@skraba.com> wrote:
> >
> > > Hey -- how does this sound for rolling out this strategy.
> > >
> > > 1) No changes to 1.11 branch. We can release 1.11.2 to bring some of
> > > the immediate bug and security fixes.
> > >
> > > 2) The next major release of Avro will be 12.0.0 for the specification
> > > and all SDK (except maybe Rust) and we'll start following semantic
> > > versioning per-SDK, with "traditional" major.minor.patch versions.
> > >
> > > 2b) The specification (and probably some other documentation) now has
> > > a version separate from the SDKs, and it'll probably stay at 12.x
> > > forever as long as we call this project Avro (no breaking changes). I
> > > agree it would be great to have a "compliance" matrix on the website!
> > >
> > > 2c) We can expect more active/experimental SDKs to go to 13.x, 14.x
> > > when breaking changes are introduced, while stable and less active
> > > SDKs to go to 12.1.x, 12.2.x ... That's fine and that's life if the
> > > major version isn't the same for SDKs -- bumping the major version
> > > doesn't mean "better". We can decide whether this is working for us
> > > during 12.x, and figure out how to address interoperability questions
> > > (between versions and between SDKs).
> > >
> > > 3) We'll have to figure out a navigation system per SDK for the
> > > website, but we'll have a bit of time to do that. Hopefully it
> > > doesn't break Martin's current investigation with branch release
> > > artifacts.
> > >
> > > 4) We can decide how many major versions remain supported per-sdk.
> > >
> > > In my opinion, the "semantic versioning" VOTE is a pre-requisite to
> > > the SDK/splitting vote -- currently I'd be confused if I saw a 1.12
> > > Avro python SDK available, but not a Java one. The big change to 12.x
> > > makes this a bit more obvious (and is also something devs have been
> > > asking for since I've been with the project!)
> > >
> > > Another thing I'd like to talk about before calling a VOTE is github
> > > branches... I've been trying to wrap my head around it, but it's still
> > > a bit unclear to me how we should manage this in a mono-repo.
> > >
> >
> > This is exactly what stopped me proceeding with the vote!
> >
> > One option is to split the monorepo to repo-per-sdk but this is a big
> task!
> >
> > The other viable option I see is to have just one branch (master) where
> all
> > SDKs evolve in their own pace and bump their versions as they need.
> > When a user asks for a maintaince release then a developer could create a
> > branch from an earlier commit (e.g. from the respective tag/release) and
> > apply the requested bug fixes. From my experience so far there were not
> > many such requests.
> > Such maintanance branches should be short lived - only for the requested
> > big fix! Once a new release is tagged, e.g. release-rust-12.1.1, then the
> > branch should be removed to avoid any confusions. Also such branches
> should
> > be used only for the release of one SDK!
> >
> > I stopped working on the PR for the asf.yaml based website because I
> > honestly have no idea how to support the split documentations per SDK per
> > version in a monorepo...
> >
> >
> >
> > >
> > > In any case, I'm motivated to keep this discussion going! :D I'd
> > > definitely vote +1 on the "should we?" but "and how?" could use a bit
> > > of refinement.
> > >
> > > All my best, Ryan
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Wed, Jan 11, 2023 at 10:12 AM Khrystyna Popadyuk
> > > <kh...@gmail.com> wrote:
> > > >
> > > > +1 for separating out the releasesе too
> > > >
> > > > On Sat, Jan 7, 2023 at 4:46 AM Ryan Blue <bl...@tabular.io> wrote:
> > > >
> > > > > +1 for separating out the releases and starting a vote on just
> that.
> > > We can
> > > > > debate the other details as we go.
> > > > >
> > > > > On Thu, Jan 5, 2023 at 12:25 PM Tim Perkins <tj...@gmail.com>
> > > wrote:
> > > > >
> > > > > > On Wed, Jan 4, 2023 at 1:15 PM Ryan Skraba <ry...@skraba.com>
> > wrote:
> > > > > >
> > > > > > > Maybe a good way to get to consensus would be to list the
> > possible
> > > > > > > actions we could take, and prioritize them?
> > > > > > >
> > > > > >
> > > > > > One of the actions that I would like to see is the compilation of
> > > which
> > > > > > parts of the spec each language implements. This would be a
> useful
> > > > > addition
> > > > > > to the documentation.
> > > > > >
> > > > > > If we compile this table it may be that it requires a lot of
> > > footnotes
> > > > > and
> > > > > > qualifications for differences in how languages implement the
> spec,
> > > but
> > > > > > overall it would still be useful to identify gaps, highlight
> > > differences,
> > > > > > and perhaps ultimately drive more compatibility.
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Ryan Blue
> > > > > Tabular
> > > > >
> > >
> >
>
Re: Release language modules separately
Posted by Christophe Le Saëc <ch...@gmail.com>.
With one github repo; how to manage share
<https://github.com/apache/avro/tree/master/share> folder ? i mean if one
version need updates on this repo but not the older.
As an example, this JIRA AVRO-3591
<https://issues.apache.org/jira/browse/AVRO-3591> aims to create commons
inter sdk unit tests (The PR <https://github.com/apache/avro/pull/1850> add
some files on share folder); commons tests could be valid for a version but
not for an older one.
Le jeu. 12 janv. 2023 à 12:24, Martin Grigorov <mg...@apache.org> a
écrit :
> On Wed, Jan 11, 2023 at 9:27 PM Ryan Skraba <ry...@skraba.com> wrote:
>
> > Hey -- how does this sound for rolling out this strategy.
> >
> > 1) No changes to 1.11 branch. We can release 1.11.2 to bring some of
> > the immediate bug and security fixes.
> >
> > 2) The next major release of Avro will be 12.0.0 for the specification
> > and all SDK (except maybe Rust) and we'll start following semantic
> > versioning per-SDK, with "traditional" major.minor.patch versions.
> >
> > 2b) The specification (and probably some other documentation) now has
> > a version separate from the SDKs, and it'll probably stay at 12.x
> > forever as long as we call this project Avro (no breaking changes). I
> > agree it would be great to have a "compliance" matrix on the website!
> >
> > 2c) We can expect more active/experimental SDKs to go to 13.x, 14.x
> > when breaking changes are introduced, while stable and less active
> > SDKs to go to 12.1.x, 12.2.x ... That's fine and that's life if the
> > major version isn't the same for SDKs -- bumping the major version
> > doesn't mean "better". We can decide whether this is working for us
> > during 12.x, and figure out how to address interoperability questions
> > (between versions and between SDKs).
> >
> > 3) We'll have to figure out a navigation system per SDK for the
> > website, but we'll have a bit of time to do that. Hopefully it
> > doesn't break Martin's current investigation with branch release
> > artifacts.
> >
> > 4) We can decide how many major versions remain supported per-sdk.
> >
> > In my opinion, the "semantic versioning" VOTE is a pre-requisite to
> > the SDK/splitting vote -- currently I'd be confused if I saw a 1.12
> > Avro python SDK available, but not a Java one. The big change to 12.x
> > makes this a bit more obvious (and is also something devs have been
> > asking for since I've been with the project!)
> >
> > Another thing I'd like to talk about before calling a VOTE is github
> > branches... I've been trying to wrap my head around it, but it's still
> > a bit unclear to me how we should manage this in a mono-repo.
> >
>
> This is exactly what stopped me proceeding with the vote!
>
> One option is to split the monorepo to repo-per-sdk but this is a big task!
>
> The other viable option I see is to have just one branch (master) where all
> SDKs evolve in their own pace and bump their versions as they need.
> When a user asks for a maintaince release then a developer could create a
> branch from an earlier commit (e.g. from the respective tag/release) and
> apply the requested bug fixes. From my experience so far there were not
> many such requests.
> Such maintanance branches should be short lived - only for the requested
> big fix! Once a new release is tagged, e.g. release-rust-12.1.1, then the
> branch should be removed to avoid any confusions. Also such branches should
> be used only for the release of one SDK!
>
> I stopped working on the PR for the asf.yaml based website because I
> honestly have no idea how to support the split documentations per SDK per
> version in a monorepo...
>
>
>
> >
> > In any case, I'm motivated to keep this discussion going! :D I'd
> > definitely vote +1 on the "should we?" but "and how?" could use a bit
> > of refinement.
> >
> > All my best, Ryan
> >
> >
> >
> >
> >
> >
> > On Wed, Jan 11, 2023 at 10:12 AM Khrystyna Popadyuk
> > <kh...@gmail.com> wrote:
> > >
> > > +1 for separating out the releasesе too
> > >
> > > On Sat, Jan 7, 2023 at 4:46 AM Ryan Blue <bl...@tabular.io> wrote:
> > >
> > > > +1 for separating out the releases and starting a vote on just that.
> > We can
> > > > debate the other details as we go.
> > > >
> > > > On Thu, Jan 5, 2023 at 12:25 PM Tim Perkins <tj...@gmail.com>
> > wrote:
> > > >
> > > > > On Wed, Jan 4, 2023 at 1:15 PM Ryan Skraba <ry...@skraba.com>
> wrote:
> > > > >
> > > > > > Maybe a good way to get to consensus would be to list the
> possible
> > > > > > actions we could take, and prioritize them?
> > > > > >
> > > > >
> > > > > One of the actions that I would like to see is the compilation of
> > which
> > > > > parts of the spec each language implements. This would be a useful
> > > > addition
> > > > > to the documentation.
> > > > >
> > > > > If we compile this table it may be that it requires a lot of
> > footnotes
> > > > and
> > > > > qualifications for differences in how languages implement the spec,
> > but
> > > > > overall it would still be useful to identify gaps, highlight
> > differences,
> > > > > and perhaps ultimately drive more compatibility.
> > > > >
> > > >
> > > >
> > > > --
> > > > Ryan Blue
> > > > Tabular
> > > >
> >
>
Re: Release language modules separately
Posted by Martin Grigorov <mg...@apache.org>.
On Wed, Jan 11, 2023 at 9:27 PM Ryan Skraba <ry...@skraba.com> wrote:
> Hey -- how does this sound for rolling out this strategy.
>
> 1) No changes to 1.11 branch. We can release 1.11.2 to bring some of
> the immediate bug and security fixes.
>
> 2) The next major release of Avro will be 12.0.0 for the specification
> and all SDK (except maybe Rust) and we'll start following semantic
> versioning per-SDK, with "traditional" major.minor.patch versions.
>
> 2b) The specification (and probably some other documentation) now has
> a version separate from the SDKs, and it'll probably stay at 12.x
> forever as long as we call this project Avro (no breaking changes). I
> agree it would be great to have a "compliance" matrix on the website!
>
> 2c) We can expect more active/experimental SDKs to go to 13.x, 14.x
> when breaking changes are introduced, while stable and less active
> SDKs to go to 12.1.x, 12.2.x ... That's fine and that's life if the
> major version isn't the same for SDKs -- bumping the major version
> doesn't mean "better". We can decide whether this is working for us
> during 12.x, and figure out how to address interoperability questions
> (between versions and between SDKs).
>
> 3) We'll have to figure out a navigation system per SDK for the
> website, but we'll have a bit of time to do that. Hopefully it
> doesn't break Martin's current investigation with branch release
> artifacts.
>
> 4) We can decide how many major versions remain supported per-sdk.
>
> In my opinion, the "semantic versioning" VOTE is a pre-requisite to
> the SDK/splitting vote -- currently I'd be confused if I saw a 1.12
> Avro python SDK available, but not a Java one. The big change to 12.x
> makes this a bit more obvious (and is also something devs have been
> asking for since I've been with the project!)
>
> Another thing I'd like to talk about before calling a VOTE is github
> branches... I've been trying to wrap my head around it, but it's still
> a bit unclear to me how we should manage this in a mono-repo.
>
This is exactly what stopped me proceeding with the vote!
One option is to split the monorepo to repo-per-sdk but this is a big task!
The other viable option I see is to have just one branch (master) where all
SDKs evolve in their own pace and bump their versions as they need.
When a user asks for a maintaince release then a developer could create a
branch from an earlier commit (e.g. from the respective tag/release) and
apply the requested bug fixes. From my experience so far there were not
many such requests.
Such maintanance branches should be short lived - only for the requested
big fix! Once a new release is tagged, e.g. release-rust-12.1.1, then the
branch should be removed to avoid any confusions. Also such branches should
be used only for the release of one SDK!
I stopped working on the PR for the asf.yaml based website because I
honestly have no idea how to support the split documentations per SDK per
version in a monorepo...
>
> In any case, I'm motivated to keep this discussion going! :D I'd
> definitely vote +1 on the "should we?" but "and how?" could use a bit
> of refinement.
>
> All my best, Ryan
>
>
>
>
>
>
> On Wed, Jan 11, 2023 at 10:12 AM Khrystyna Popadyuk
> <kh...@gmail.com> wrote:
> >
> > +1 for separating out the releasesе too
> >
> > On Sat, Jan 7, 2023 at 4:46 AM Ryan Blue <bl...@tabular.io> wrote:
> >
> > > +1 for separating out the releases and starting a vote on just that.
> We can
> > > debate the other details as we go.
> > >
> > > On Thu, Jan 5, 2023 at 12:25 PM Tim Perkins <tj...@gmail.com>
> wrote:
> > >
> > > > On Wed, Jan 4, 2023 at 1:15 PM Ryan Skraba <ry...@skraba.com> wrote:
> > > >
> > > > > Maybe a good way to get to consensus would be to list the possible
> > > > > actions we could take, and prioritize them?
> > > > >
> > > >
> > > > One of the actions that I would like to see is the compilation of
> which
> > > > parts of the spec each language implements. This would be a useful
> > > addition
> > > > to the documentation.
> > > >
> > > > If we compile this table it may be that it requires a lot of
> footnotes
> > > and
> > > > qualifications for differences in how languages implement the spec,
> but
> > > > overall it would still be useful to identify gaps, highlight
> differences,
> > > > and perhaps ultimately drive more compatibility.
> > > >
> > >
> > >
> > > --
> > > Ryan Blue
> > > Tabular
> > >
>
Re: Release language modules separately
Posted by Ryan Skraba <ry...@skraba.com>.
Hey -- how does this sound for rolling out this strategy.
1) No changes to 1.11 branch. We can release 1.11.2 to bring some of
the immediate bug and security fixes.
2) The next major release of Avro will be 12.0.0 for the specification
and all SDK (except maybe Rust) and we'll start following semantic
versioning per-SDK, with "traditional" major.minor.patch versions.
2b) The specification (and probably some other documentation) now has
a version separate from the SDKs, and it'll probably stay at 12.x
forever as long as we call this project Avro (no breaking changes). I
agree it would be great to have a "compliance" matrix on the website!
2c) We can expect more active/experimental SDKs to go to 13.x, 14.x
when breaking changes are introduced, while stable and less active
SDKs to go to 12.1.x, 12.2.x ... That's fine and that's life if the
major version isn't the same for SDKs -- bumping the major version
doesn't mean "better". We can decide whether this is working for us
during 12.x, and figure out how to address interoperability questions
(between versions and between SDKs).
3) We'll have to figure out a navigation system per SDK for the
website, but we'll have a bit of time to do that. Hopefully it
doesn't break Martin's current investigation with branch release
artifacts.
4) We can decide how many major versions remain supported per-sdk.
In my opinion, the "semantic versioning" VOTE is a pre-requisite to
the SDK/splitting vote -- currently I'd be confused if I saw a 1.12
Avro python SDK available, but not a Java one. The big change to 12.x
makes this a bit more obvious (and is also something devs have been
asking for since I've been with the project!)
Another thing I'd like to talk about before calling a VOTE is github
branches... I've been trying to wrap my head around it, but it's still
a bit unclear to me how we should manage this in a mono-repo.
In any case, I'm motivated to keep this discussion going! :D I'd
definitely vote +1 on the "should we?" but "and how?" could use a bit
of refinement.
All my best, Ryan
On Wed, Jan 11, 2023 at 10:12 AM Khrystyna Popadyuk
<kh...@gmail.com> wrote:
>
> +1 for separating out the releasesе too
>
> On Sat, Jan 7, 2023 at 4:46 AM Ryan Blue <bl...@tabular.io> wrote:
>
> > +1 for separating out the releases and starting a vote on just that. We can
> > debate the other details as we go.
> >
> > On Thu, Jan 5, 2023 at 12:25 PM Tim Perkins <tj...@gmail.com> wrote:
> >
> > > On Wed, Jan 4, 2023 at 1:15 PM Ryan Skraba <ry...@skraba.com> wrote:
> > >
> > > > Maybe a good way to get to consensus would be to list the possible
> > > > actions we could take, and prioritize them?
> > > >
> > >
> > > One of the actions that I would like to see is the compilation of which
> > > parts of the spec each language implements. This would be a useful
> > addition
> > > to the documentation.
> > >
> > > If we compile this table it may be that it requires a lot of footnotes
> > and
> > > qualifications for differences in how languages implement the spec, but
> > > overall it would still be useful to identify gaps, highlight differences,
> > > and perhaps ultimately drive more compatibility.
> > >
> >
> >
> > --
> > Ryan Blue
> > Tabular
> >
Re: Release language modules separately
Posted by Khrystyna Popadyuk <kh...@gmail.com>.
+1 for separating out the releasesе too
On Sat, Jan 7, 2023 at 4:46 AM Ryan Blue <bl...@tabular.io> wrote:
> +1 for separating out the releases and starting a vote on just that. We can
> debate the other details as we go.
>
> On Thu, Jan 5, 2023 at 12:25 PM Tim Perkins <tj...@gmail.com> wrote:
>
> > On Wed, Jan 4, 2023 at 1:15 PM Ryan Skraba <ry...@skraba.com> wrote:
> >
> > > Maybe a good way to get to consensus would be to list the possible
> > > actions we could take, and prioritize them?
> > >
> >
> > One of the actions that I would like to see is the compilation of which
> > parts of the spec each language implements. This would be a useful
> addition
> > to the documentation.
> >
> > If we compile this table it may be that it requires a lot of footnotes
> and
> > qualifications for differences in how languages implement the spec, but
> > overall it would still be useful to identify gaps, highlight differences,
> > and perhaps ultimately drive more compatibility.
> >
>
>
> --
> Ryan Blue
> Tabular
>
Re: Release language modules separately
Posted by Ryan Blue <bl...@tabular.io>.
+1 for separating out the releases and starting a vote on just that. We can
debate the other details as we go.
On Thu, Jan 5, 2023 at 12:25 PM Tim Perkins <tj...@gmail.com> wrote:
> On Wed, Jan 4, 2023 at 1:15 PM Ryan Skraba <ry...@skraba.com> wrote:
>
> > Maybe a good way to get to consensus would be to list the possible
> > actions we could take, and prioritize them?
> >
>
> One of the actions that I would like to see is the compilation of which
> parts of the spec each language implements. This would be a useful addition
> to the documentation.
>
> If we compile this table it may be that it requires a lot of footnotes and
> qualifications for differences in how languages implement the spec, but
> overall it would still be useful to identify gaps, highlight differences,
> and perhaps ultimately drive more compatibility.
>
--
Ryan Blue
Tabular
Re: Release language modules separately
Posted by Tim Perkins <tj...@gmail.com>.
On Wed, Jan 4, 2023 at 1:15 PM Ryan Skraba <ry...@skraba.com> wrote:
> Maybe a good way to get to consensus would be to list the possible
> actions we could take, and prioritize them?
>
One of the actions that I would like to see is the compilation of which
parts of the spec each language implements. This would be a useful addition
to the documentation.
If we compile this table it may be that it requires a lot of footnotes and
qualifications for differences in how languages implement the spec, but
overall it would still be useful to identify gaps, highlight differences,
and perhaps ultimately drive more compatibility.
Re: Release language modules separately
Posted by Ryan Skraba <ry...@skraba.com>.
Hello! We've started and stopped this discussion a couple of times --
but it ends up getting a bit bogged down in details, and there's so
much going on that we end on sticking with the status quo!
I would love to have this discussion again though and come to a
conclusion. We could be doing quite a few things better, and changing
our release strategy to a more flexible and modern style is likely
going to make things easier for us in the long run.
Among the related topics are:
1) Moving to more recognizable semantic versioning (i.e., dropping the
"1." prefix in Avro).
2) Versioning the website and specification for releases.
3) Supporting N minor releases simultaneously (where N is more than 1)
4) Splitting the language SDKs to separate releases and releasing separately.
Just for reference, I always like to link the thread to the last time
we discussed (which links to the previous years). There's quite a few
good points! I don't think we can ever really satisfy everyone, but
we can definitely make changes.
Maybe a good way to get to consensus would be to list the possible
actions we could take, and prioritize them?
Thanks for bringing this up and HAPPY NEW YEAR everybody!
Ryan
[1]: https://lists.apache.org/thread/rybf7vb514mtkr7swfld7b06g1kb2r3t
"[DISCUSS] Releases, versioning and lifecycle"
On Wed, Jan 4, 2023 at 1:05 PM Oscar Westra van Holthe - Kind
<os...@westravanholthe.nl> wrote:
>
> On Wed, 4 Jan 2023 at 08:15, Martin Grigorov <mg...@apache.org> wrote:
> > [...] the problem is the availability of active maintainers.
>
> This is another issue, and important too IMHO. I'm just not certain there's
> a solution though.
> I'll raise another thread if I ever have ideas to tackle it.
>
> Kind regards,
> Oscar
>
> --
>
> ✉️ Oscar Westra van Holthe - Kind <os...@westravanholthe.nl>
Re: Release language modules separately
Posted by Oscar Westra van Holthe - Kind <os...@westravanholthe.nl>.
On Wed, 4 Jan 2023 at 08:15, Martin Grigorov <mg...@apache.org> wrote:
> [...] the problem is the availability of active maintainers.
This is another issue, and important too IMHO. I'm just not certain there's
a solution though.
I'll raise another thread if I ever have ideas to tackle it.
Kind regards,
Oscar
--
✉️ Oscar Westra van Holthe - Kind <os...@westravanholthe.nl>
Re: Release language modules separately
Posted by Martin Grigorov <mg...@apache.org>.
Hi Oscar,
On Wed, Jan 4, 2023 at 9:01 AM Oscar Westra van Holthe - Kind <
oscar@westravanholthe.nl> wrote:
> Happy new year!
>
> While the frustration of a slow release cadence is something I feel as
> well, splitting the release will not help there. It really boils down to
> how often we want to do a release, and specifically how fast we can merge
> PRs (safely). If we cannot speed that up, releasing more often won't help.
>
Here the problem is the availability of active maintainers.
My idea is that tThe lack of help for reviewing and merging PRs for lang X
should not stop the activity in lang Y,
i.e. lang Y should be able to make new releases.
>
> Having said that, it's a good idea to split releases anyway. It makes no
> sense to release a module that hasn't changed, or give a module a large
> version increase if it only has updated dependencies.
>
> I do agree with the implied proposal to keep the current semantic
> versioning scheme: spec.major.minor, where the spec version denotes
> compatibility of the binary format and parsing canonical form. That makes
> it possible to at least have some idea about interoperability without
> consulting a lookup table.
>
> Kind regards,
> Oscar
>
> --
> Oscar Westra van Holthe - Kind <os...@westravanholthe.nl>
>
> Op di 3 jan. 2023 15:01 schreef Martin Grigorov <mg...@apache.org>:
>
> > Happy new year Avro community!
> > I wish you to have a lot of fun while developing your projects!
> >
> > I'd like to propose to make it possible to release a single module/lang.
> > At the moment all modules share the same version and are being released
> > together.
> > The problem is that the release cadence is rather slow and some users
> > complain about it, e.g. the C# and Rust ones.
> >
> > The only "problem" I see is that the modules will have different versions
> > from now on, e.g. Java will be 1.11.1 and the C# module will be 1.12.0.
> > (The Rust one is still at 0.15.0 :-) ).
> > This might confuse some users but we just have to make it clear in the
> docs
> > that the important number is the Avro spec version, i.e. "1". The modules
> > do not implement the whole set of features
> > even now.
> >
> > As of now, a release of a single module (or a sub-set of modules) will
> > require the same ASF release rules (3 binding +1s, at least 72 hours for
> > voting, etc.).
> >
> > What do you think ?
> >
> > Regards,
> > Martin
> >
>
Re: Release language modules separately
Posted by Oscar Westra van Holthe - Kind <os...@westravanholthe.nl>.
Happy new year!
While the frustration of a slow release cadence is something I feel as
well, splitting the release will not help there. It really boils down to
how often we want to do a release, and specifically how fast we can merge
PRs (safely). If we cannot speed that up, releasing more often won't help.
Having said that, it's a good idea to split releases anyway. It makes no
sense to release a module that hasn't changed, or give a module a large
version increase if it only has updated dependencies.
I do agree with the implied proposal to keep the current semantic
versioning scheme: spec.major.minor, where the spec version denotes
compatibility of the binary format and parsing canonical form. That makes
it possible to at least have some idea about interoperability without
consulting a lookup table.
Kind regards,
Oscar
--
Oscar Westra van Holthe - Kind <os...@westravanholthe.nl>
Op di 3 jan. 2023 15:01 schreef Martin Grigorov <mg...@apache.org>:
> Happy new year Avro community!
> I wish you to have a lot of fun while developing your projects!
>
> I'd like to propose to make it possible to release a single module/lang.
> At the moment all modules share the same version and are being released
> together.
> The problem is that the release cadence is rather slow and some users
> complain about it, e.g. the C# and Rust ones.
>
> The only "problem" I see is that the modules will have different versions
> from now on, e.g. Java will be 1.11.1 and the C# module will be 1.12.0.
> (The Rust one is still at 0.15.0 :-) ).
> This might confuse some users but we just have to make it clear in the docs
> that the important number is the Avro spec version, i.e. "1". The modules
> do not implement the whole set of features
> even now.
>
> As of now, a release of a single module (or a sub-set of modules) will
> require the same ASF release rules (3 binding +1s, at least 72 hours for
> voting, etc.).
>
> What do you think ?
>
> Regards,
> Martin
>
Re: Release language modules separately
Posted by Martin Grigorov <mg...@apache.org>.
Hello Khrystyna,
On Wed, Jan 4, 2023 at 2:31 AM Khrystyna Popadyuk <
khrystyna.popadyuk@gmail.com> wrote:
> Hi Martin,
>
> Happy new year too!
>
> I think a split release for modules/languages is a great idea.
>
> As we are going to have different versions for different languages, is
> there a sense to continue linking package version to specification version?
> You mentioned that modules that have version 1.*.* do not actually
> implement all features of specification. Also from my experience different
> languages/ modules missed different parts of specification.
> It looks to me that the statement "package with version 1.*.* implement
> specification with version 1*" is not completely correct.
>
Well, we could say that the package with version 1.x.y aims to implement
Avro spec v1.
There are parts of the spec which are optional, so it is OK such to be
missing.
The non-optional parts should be implemented sooner or later! But 1.x.y is
still correct, IMO.
>
> What about moving to semantic versioning? Where major version means
breaking changes, minor - new feature and patch - bug fix.
> In this case each language would be able to change its own version
> independently and the version will reflect what exactly changed. This also
> can help with introducing breaking changes if needed - users will clearly
> know if there is breaking changes or not.
> Specification version can be added to package description, so we still
> indicate what specification version is implemented by concrete package.
>
> What do you think about using semantic versioning?
>
We do follow semantic versioning even now, but in "1.x.y" the "major"
number is "x" and "y" is the minor one.
A patch release would be something like 1.11.1.1.
>
> Best Regards,
> Khrystyna
>
> On Wed, Jan 4, 2023 at 1:02 AM Martin Grigorov <mg...@apache.org>
> wrote:
>
> > Happy new year Avro community!
> > I wish you to have a lot of fun while developing your projects!
> >
> > I'd like to propose to make it possible to release a single module/lang.
> > At the moment all modules share the same version and are being released
> > together.
> > The problem is that the release cadence is rather slow and some users
> > complain about it, e.g. the C# and Rust ones.
> >
> > The only "problem" I see is that the modules will have different versions
> > from now on, e.g. Java will be 1.11.1 and the C# module will be 1.12.0.
> > (The Rust one is still at 0.15.0 :-) ).
> > This might confuse some users but we just have to make it clear in the
> docs
> > that the important number is the Avro spec version, i.e. "1". The modules
> > do not implement the whole set of features
> > even now.
> >
> > As of now, a release of a single module (or a sub-set of modules) will
> > require the same ASF release rules (3 binding +1s, at least 72 hours for
> > voting, etc.).
> >
> > What do you think ?
> >
> > Regards,
> > Martin
> >
>
Re: Release language modules separately
Posted by Khrystyna Popadyuk <kh...@gmail.com>.
Hi Martin,
Happy new year too!
I think a split release for modules/languages is a great idea.
As we are going to have different versions for different languages, is
there a sense to continue linking package version to specification version?
You mentioned that modules that have version 1.*.* do not actually
implement all features of specification. Also from my experience different
languages/ modules missed different parts of specification.
It looks to me that the statement "package with version 1.*.* implement
specification with version 1*" is not completely correct.
What about moving to semantic versioning? Where major version means
breaking changes, minor - new feature and patch - bug fix.
In this case each language would be able to change its own version
independently and the version will reflect what exactly changed. This also
can help with introducing breaking changes if needed - users will clearly
know if there is breaking changes or not.
Specification version can be added to package description, so we still
indicate what specification version is implemented by concrete package.
What do you think about using semantic versioning?
Best Regards,
Khrystyna
On Wed, Jan 4, 2023 at 1:02 AM Martin Grigorov <mg...@apache.org> wrote:
> Happy new year Avro community!
> I wish you to have a lot of fun while developing your projects!
>
> I'd like to propose to make it possible to release a single module/lang.
> At the moment all modules share the same version and are being released
> together.
> The problem is that the release cadence is rather slow and some users
> complain about it, e.g. the C# and Rust ones.
>
> The only "problem" I see is that the modules will have different versions
> from now on, e.g. Java will be 1.11.1 and the C# module will be 1.12.0.
> (The Rust one is still at 0.15.0 :-) ).
> This might confuse some users but we just have to make it clear in the docs
> that the important number is the Avro spec version, i.e. "1". The modules
> do not implement the whole set of features
> even now.
>
> As of now, a release of a single module (or a sub-set of modules) will
> require the same ASF release rules (3 binding +1s, at least 72 hours for
> voting, etc.).
>
> What do you think ?
>
> Regards,
> Martin
>