Date   

Re: Projects included into Sandbox from the 1/26 sandbox review meeting

Chris Aniszczyk
 

It's https://github.com/docker/distribution

They will pick a new org name and so on.

On Tue, Jan 26, 2021 at 12:34 PM Joe Beda <jbeda@...> wrote:

Hi all,

 

Does anyone have details on what “Distribution” is? That is a super generic name and the linked issue doesn’t have any pointers to other resources to orient me.

 

Joe

 

From: cncf-toc@... <cncf-toc@...> on behalf of Amye Scavarda Perrin <ascavarda@...>
Date: Tuesday, January 26, 2021 at 9:52 AM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] Projects included into Sandbox from the 1/26 sandbox review meeting

The TOC has reviewed the projects that have applied to be included in Sandbox, see the results below. 

Our next Sandbox review meeting is March 23, 2021. 


GitOps Working Group
 passes with a majority vote of the TOC
Piraeus-Datastore
 passes with a majority vote of the TOC
cloudquery
 not included
calabash
 not included
Tuna Lang
 not included
KubeInvaders
 License issues need to be reviewed before this can be included
Curiefense
 passes with a majority vote of the TOC
Athenz
 passes with a majority vote of the TOC
Kube-OVN
 passes with a majority vote of the TOC
k8dash
 passes with a majority vote of the TOC - but TOC would like the project to rename to reduce confusion
Distribution
 passes with a majority vote of the TOC

 

--

Amye Scavarda Perrin | Program Manager | amye@...



--
Chris Aniszczyk (@cra)


Re: Projects included into Sandbox from the 1/26 sandbox review meeting

Joe Beda <jbeda@...>
 

Hi all,

 

Does anyone have details on what “Distribution” is? That is a super generic name and the linked issue doesn’t have any pointers to other resources to orient me.

 

Joe

 

From: cncf-toc@... <cncf-toc@...> on behalf of Amye Scavarda Perrin <ascavarda@...>
Date: Tuesday, January 26, 2021 at 9:52 AM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] Projects included into Sandbox from the 1/26 sandbox review meeting

The TOC has reviewed the projects that have applied to be included in Sandbox, see the results below. 

Our next Sandbox review meeting is March 23, 2021. 


GitOps Working Group
 passes with a majority vote of the TOC
Piraeus-Datastore
 passes with a majority vote of the TOC
cloudquery
 not included
calabash
 not included
Tuna Lang
 not included
KubeInvaders
 License issues need to be reviewed before this can be included
Curiefense
 passes with a majority vote of the TOC
Athenz
 passes with a majority vote of the TOC
Kube-OVN
 passes with a majority vote of the TOC
k8dash
 passes with a majority vote of the TOC - but TOC would like the project to rename to reduce confusion
Distribution
 passes with a majority vote of the TOC

 

--

Amye Scavarda Perrin | Program Manager | amye@...


Projects included into Sandbox from the 1/26 sandbox review meeting

Amye Scavarda Perrin
 

The TOC has reviewed the projects that have applied to be included in Sandbox, see the results below. 
Our next Sandbox review meeting is March 23, 2021. 

GitOps Working Group
 passes with a majority vote of the TOC
Piraeus-Datastore
 passes with a majority vote of the TOC
cloudquery
 not included
calabash
 not included
Tuna Lang
 not included
KubeInvaders
 License issues need to be reviewed before this can be included
Curiefense
 passes with a majority vote of the TOC
Athenz
 passes with a majority vote of the TOC
Kube-OVN
 passes with a majority vote of the TOC
k8dash
 passes with a majority vote of the TOC - but TOC would like the project to rename to reduce confusion
Distribution
 passes with a majority vote of the TOC

--
Amye Scavarda Perrin | Program Manager | amye@...


[TOC Election] Qualified Nominees for January/February 2021 Election

Amye Scavarda Perrin
 

Congratulations to our nominees for the Technical Oversight Committee! 

These nominees have all passed the qualification process from the Governing Board and TOC.

Ricardo Aravena
John Belamaric
Erin Boyd
Cornelia Davis
Bridget Kromhout
Edward Lee
Michael Lieberman
Paul Morie
Ricardo Rocha
Davanum Srinivas
Carolyn Van Slyck
Kevin (Zefeng) Wang
Lei Zhang
Dave Zolotusky

Voting is now open for the five (5) seats available: three (3) from the Governing Board, and two (2) from the End Users community.

Voting will close on February 1, 2021 at 11:59am Pacific time (roughly noon), and the election results will be announced on February 1st.

--
Amye Scavarda Perrin | Program Manager | amye@...


Re: Apologies

Michelle Noorali <michelle.noorali@...>
 

I will have to skip as well. Please let me know where I can help.

Michelle 

On Jan 18, 2021, at 1:10 PM, Justin Cormack via lists.cncf.io <justin.cormack=docker.com@...> wrote:


I have as well, apologies too. 

Justin


On Mon, 18 Jan 2021 at 11:28, Liz Rice <liz@...> wrote:
Sorry folks, I've got a conflict for tomorrow's TOC meeting, and I will have to skip this one

Liz


Re: Apologies

Justin Cormack
 

I have as well, apologies too. 

Justin


On Mon, 18 Jan 2021 at 11:28, Liz Rice <liz@...> wrote:
Sorry folks, I've got a conflict for tomorrow's TOC meeting, and I will have to skip this one

Liz


Apologies

Liz Rice
 

Sorry folks, I've got a conflict for tomorrow's TOC meeting, and I will have to skip this one

Liz


Re: [EXTERNAL] [cncf-toc] What do we mean by “Version 1.0”?

Liz Rice
 

I realise that many enterprise users still see 1.0 as being the first production ready version.  Much as Quinton says.

I think that's the heart of the confusion / expectation that I'm seeing. (Or even more precisely that anything under v1.0 is seen by many as not production-ready.) Ack that not every project sees it the same way.

Three concrete suggestions: 

1. Incubation criteria already has a requirement for "A clear versioning scheme" but it doesn't say why. Suggestion:  "A clear versioning scheme, such as semantic versioning or other clearly-defined scheme from which compatibility expectations can be inferred." 

2. Incubation criteria already says that a project must be "used successfully in production by at least three independent end users", and we say here that Graduation means we think the project is ready for adoption by Early Majority organizations. These combined imply "production readiness" at graduation level, but we don't explicitly say it. Suggestion: add to graduation stage criteria "Ready for production use by end user organizations."

3. Following on from 1 & 2, also add to graduation stage criteria "...with release numbering that complies with the project's version numbering scheme, and indicates production readiness."
 

On Fri, Jan 15, 2021 at 9:23 AM alexis richardson <alexis@...> wrote:
if CNCF wants to help, then publish some guidelines.  Or, people will just do their own thing.


On Fri, Jan 15, 2021 at 9:15 AM Gareth Rushgrove <gareth@...> wrote:
On Thu, 14 Jan 2021 at 19:25, Matt Farina <matt@...> wrote:
>
> I think there is some nuance in here but it's worth discussing.
>
> For example, if a project is using SemVer there are a couple parts of the spec that come to mind...
>

Let's face it. Most uses of x.y.z aren't SemVer and most people
haven't read the spec :)

I think something about graduated projects having a documented policy
around versioning is probably worthwhile, that feels like a useful
maturity gauge.

In the wider software ecosystem you see examples of popular and widely
adopted software with most types of version numbers. I think
consistency within a project is important, but it doesn't appear the
market in general cares that much about consistency between different
projects.

Gareth


> 4. Major version zero (0.y.z) is for initial development.
>
>
> If a project doesn't have a 1.0.0 yet and it's using SemVer than I don't think it should be graduated because it's still in initial development.
>
> I realize different people do different things with versions. But, versions are about communication. Graduated projects should be clear on their communication of versions.
>
> 1. Software using Semantic Versioning MUST declare a public API.
>
>
> and
>
> 8. Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API.
>
>
> and on the CNCF projects page it talks about Graduated Projects being for the majority. They aren't experiments but things that more cautious businesses can adopt.
>
> A graduated project should state what it's API is (network, library interface, UI output, etc) and then properly version that so that consumers can know what they are getting and when things will change.
>
> These are policy based and different projects can do different things. For example, Kubernetes does not follow SemVer but does specify what is in the supported API policy and how it changes. Helm does something similar with the Go API and output from helm commands. For example, on Helm we have one place where the date format is different from the rest in the output but we can't change that until Helm v4 as a default because we know external tools parse that output.
>
> I would expect graduated projects to do things in a way that communicates clearly on what's happening with versions and have stable releases.
>
> Just my 2 cents.
>
> - Matt Farina
>
> On Thu, Jan 14, 2021, at 1:33 PM, alexis richardson wrote:
>
> IMO, everyone's using version numbers in different ways now.  For example many projects go to 1.0 once they are feature complete, and hit production way before that.  I think insisting on 1.0 for graduation is unfair and not very helpful.
>
> I realise that many enterprise users still see 1.0 as being the first production ready version.  Much as Quinton says.
>
> So, I suggest we leave everything as it is, and make sure that our own graduation criteria are clear.
>
>
>
> On Thu, 14 Jan 2021, 18:27 Quinton Hoole, <quinton@...> wrote:
>
> I'm not convinced that in people's minds, or practically, v1.0 and Graduated mean similar things. As a concrete example, Kubernetes went to v 1.0 several years before it graduated.  In my mind, version numbers tend to denote the maturity of the software. Graduation levels add to that the maturity of the process and community around the software.
>
> I do however think that there would be value striving for some amount of consistency in the semantics of version numbering across CNCF projects (possibly) to avoid the kind of confusion that Liz ran into.  I don't know exactly what that would look like, but I imagine something along the lines of:
>
> - pre 1.0 denotes "not recommended for production use"
> - post x.y denotes "go for it, people are starting to use it successfully in production"
> - post p.q denotes "rock solid, widely used in production - almost definitely graduated unless there are extenuating circumstances"
>
> ... and so on might make sense.
>
> This detail may well have been debated in depth elsewhere in the CNCF, in which case I apologise for not being up to speed on that :-)
>
> Q
>
>
> On Thu, Jan 14, 2021 at 9:50 AM Michelle Noorali via lists.cncf.io <michelle.noorali=microsoft.com@...> wrote:
>
> +1 imo a graduated project should have some documented backward compatibility guarantees and semantic versioning helps denote this. It has been a best practice on all the projects I've worked on. I'd be supportive of adding a criteria around stability and defining what that means and recommending using a semantic version to denote this for graduation.
>
> ________________________________
> From: cncf-toc@... <cncf-toc@...> on behalf of Liz Rice via lists.cncf.io <liz=lizrice.com@...>
> Sent: Thursday, January 14, 2021 12:26 PM
> To: cncf-toc@... <cncf-toc@...>
> Subject: [EXTERNAL] [cncf-toc] What do we mean by “Version 1.0”?
>
> Hi folks,
>
> Someone I spoke with today said something along the lines “if <this project> is stable, why is it still at v0.something?” and that got me thinking - does it make any sense to expect Graduated projects to be at v1.0 or above?
>
> I know this is easily gamed, in the sense that project maintainers can release any version number they like, but let’s set that aside for now and assume that maintainers are well intentioned. I wonder if the signals that are sent by releasing a v1.0 are similar to what Graduation means?
>
> (I have not checked the version numbers of existing graduated projects)
>
> Thoughts?
>
> Liz
>
>
>
>
>
> --
> Quinton Hoole
> quinton@...
>
>
>
>
>



--
Gareth Rushgrove
@garethr

garethr.dev
devopsweekly.com






Re: [EXTERNAL] [cncf-toc] What do we mean by “Version 1.0”?

alexis richardson
 

if CNCF wants to help, then publish some guidelines.  Or, people will just do their own thing.


On Fri, Jan 15, 2021 at 9:15 AM Gareth Rushgrove <gareth@...> wrote:
On Thu, 14 Jan 2021 at 19:25, Matt Farina <matt@...> wrote:
>
> I think there is some nuance in here but it's worth discussing.
>
> For example, if a project is using SemVer there are a couple parts of the spec that come to mind...
>

Let's face it. Most uses of x.y.z aren't SemVer and most people
haven't read the spec :)

I think something about graduated projects having a documented policy
around versioning is probably worthwhile, that feels like a useful
maturity gauge.

In the wider software ecosystem you see examples of popular and widely
adopted software with most types of version numbers. I think
consistency within a project is important, but it doesn't appear the
market in general cares that much about consistency between different
projects.

Gareth


> 4. Major version zero (0.y.z) is for initial development.
>
>
> If a project doesn't have a 1.0.0 yet and it's using SemVer than I don't think it should be graduated because it's still in initial development.
>
> I realize different people do different things with versions. But, versions are about communication. Graduated projects should be clear on their communication of versions.
>
> 1. Software using Semantic Versioning MUST declare a public API.
>
>
> and
>
> 8. Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API.
>
>
> and on the CNCF projects page it talks about Graduated Projects being for the majority. They aren't experiments but things that more cautious businesses can adopt.
>
> A graduated project should state what it's API is (network, library interface, UI output, etc) and then properly version that so that consumers can know what they are getting and when things will change.
>
> These are policy based and different projects can do different things. For example, Kubernetes does not follow SemVer but does specify what is in the supported API policy and how it changes. Helm does something similar with the Go API and output from helm commands. For example, on Helm we have one place where the date format is different from the rest in the output but we can't change that until Helm v4 as a default because we know external tools parse that output.
>
> I would expect graduated projects to do things in a way that communicates clearly on what's happening with versions and have stable releases.
>
> Just my 2 cents.
>
> - Matt Farina
>
> On Thu, Jan 14, 2021, at 1:33 PM, alexis richardson wrote:
>
> IMO, everyone's using version numbers in different ways now.  For example many projects go to 1.0 once they are feature complete, and hit production way before that.  I think insisting on 1.0 for graduation is unfair and not very helpful.
>
> I realise that many enterprise users still see 1.0 as being the first production ready version.  Much as Quinton says.
>
> So, I suggest we leave everything as it is, and make sure that our own graduation criteria are clear.
>
>
>
> On Thu, 14 Jan 2021, 18:27 Quinton Hoole, <quinton@...> wrote:
>
> I'm not convinced that in people's minds, or practically, v1.0 and Graduated mean similar things. As a concrete example, Kubernetes went to v 1.0 several years before it graduated.  In my mind, version numbers tend to denote the maturity of the software. Graduation levels add to that the maturity of the process and community around the software.
>
> I do however think that there would be value striving for some amount of consistency in the semantics of version numbering across CNCF projects (possibly) to avoid the kind of confusion that Liz ran into.  I don't know exactly what that would look like, but I imagine something along the lines of:
>
> - pre 1.0 denotes "not recommended for production use"
> - post x.y denotes "go for it, people are starting to use it successfully in production"
> - post p.q denotes "rock solid, widely used in production - almost definitely graduated unless there are extenuating circumstances"
>
> ... and so on might make sense.
>
> This detail may well have been debated in depth elsewhere in the CNCF, in which case I apologise for not being up to speed on that :-)
>
> Q
>
>
> On Thu, Jan 14, 2021 at 9:50 AM Michelle Noorali via lists.cncf.io <michelle.noorali=microsoft.com@...> wrote:
>
> +1 imo a graduated project should have some documented backward compatibility guarantees and semantic versioning helps denote this. It has been a best practice on all the projects I've worked on. I'd be supportive of adding a criteria around stability and defining what that means and recommending using a semantic version to denote this for graduation.
>
> ________________________________
> From: cncf-toc@... <cncf-toc@...> on behalf of Liz Rice via lists.cncf.io <liz=lizrice.com@...>
> Sent: Thursday, January 14, 2021 12:26 PM
> To: cncf-toc@... <cncf-toc@...>
> Subject: [EXTERNAL] [cncf-toc] What do we mean by “Version 1.0”?
>
> Hi folks,
>
> Someone I spoke with today said something along the lines “if <this project> is stable, why is it still at v0.something?” and that got me thinking - does it make any sense to expect Graduated projects to be at v1.0 or above?
>
> I know this is easily gamed, in the sense that project maintainers can release any version number they like, but let’s set that aside for now and assume that maintainers are well intentioned. I wonder if the signals that are sent by releasing a v1.0 are similar to what Graduation means?
>
> (I have not checked the version numbers of existing graduated projects)
>
> Thoughts?
>
> Liz
>
>
>
>
>
> --
> Quinton Hoole
> quinton@...
>
>
>
>
>



--
Gareth Rushgrove
@garethr

garethr.dev
devopsweekly.com






Re: [EXTERNAL] [cncf-toc] What do we mean by “Version 1.0”?

Gareth Rushgrove
 

On Thu, 14 Jan 2021 at 19:25, Matt Farina <matt@mattfarina.com> wrote:

I think there is some nuance in here but it's worth discussing.

For example, if a project is using SemVer there are a couple parts of the spec that come to mind...
Let's face it. Most uses of x.y.z aren't SemVer and most people
haven't read the spec :)

I think something about graduated projects having a documented policy
around versioning is probably worthwhile, that feels like a useful
maturity gauge.

In the wider software ecosystem you see examples of popular and widely
adopted software with most types of version numbers. I think
consistency within a project is important, but it doesn't appear the
market in general cares that much about consistency between different
projects.

Gareth


4. Major version zero (0.y.z) is for initial development.


If a project doesn't have a 1.0.0 yet and it's using SemVer than I don't think it should be graduated because it's still in initial development.

I realize different people do different things with versions. But, versions are about communication. Graduated projects should be clear on their communication of versions.

1. Software using Semantic Versioning MUST declare a public API.


and

8. Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API.


and on the CNCF projects page it talks about Graduated Projects being for the majority. They aren't experiments but things that more cautious businesses can adopt.

A graduated project should state what it's API is (network, library interface, UI output, etc) and then properly version that so that consumers can know what they are getting and when things will change.

These are policy based and different projects can do different things. For example, Kubernetes does not follow SemVer but does specify what is in the supported API policy and how it changes. Helm does something similar with the Go API and output from helm commands. For example, on Helm we have one place where the date format is different from the rest in the output but we can't change that until Helm v4 as a default because we know external tools parse that output.

I would expect graduated projects to do things in a way that communicates clearly on what's happening with versions and have stable releases.

Just my 2 cents.

- Matt Farina

On Thu, Jan 14, 2021, at 1:33 PM, alexis richardson wrote:

IMO, everyone's using version numbers in different ways now. For example many projects go to 1.0 once they are feature complete, and hit production way before that. I think insisting on 1.0 for graduation is unfair and not very helpful.

I realise that many enterprise users still see 1.0 as being the first production ready version. Much as Quinton says.

So, I suggest we leave everything as it is, and make sure that our own graduation criteria are clear.



On Thu, 14 Jan 2021, 18:27 Quinton Hoole, <quinton@hoole.biz> wrote:

I'm not convinced that in people's minds, or practically, v1.0 and Graduated mean similar things. As a concrete example, Kubernetes went to v 1.0 several years before it graduated. In my mind, version numbers tend to denote the maturity of the software. Graduation levels add to that the maturity of the process and community around the software.

I do however think that there would be value striving for some amount of consistency in the semantics of version numbering across CNCF projects (possibly) to avoid the kind of confusion that Liz ran into. I don't know exactly what that would look like, but I imagine something along the lines of:

- pre 1.0 denotes "not recommended for production use"
- post x.y denotes "go for it, people are starting to use it successfully in production"
- post p.q denotes "rock solid, widely used in production - almost definitely graduated unless there are extenuating circumstances"

... and so on might make sense.

This detail may well have been debated in depth elsewhere in the CNCF, in which case I apologise for not being up to speed on that :-)

Q


On Thu, Jan 14, 2021 at 9:50 AM Michelle Noorali via lists.cncf.io <michelle.noorali=microsoft.com@lists.cncf.io> wrote:

+1 imo a graduated project should have some documented backward compatibility guarantees and semantic versioning helps denote this. It has been a best practice on all the projects I've worked on. I'd be supportive of adding a criteria around stability and defining what that means and recommending using a semantic version to denote this for graduation.

________________________________
From: cncf-toc@lists.cncf.io <cncf-toc@lists.cncf.io> on behalf of Liz Rice via lists.cncf.io <liz=lizrice.com@lists.cncf.io>
Sent: Thursday, January 14, 2021 12:26 PM
To: cncf-toc@lists.cncf.io <cncf-toc@lists.cncf.io>
Subject: [EXTERNAL] [cncf-toc] What do we mean by “Version 1.0”?

Hi folks,

Someone I spoke with today said something along the lines “if <this project> is stable, why is it still at v0.something?” and that got me thinking - does it make any sense to expect Graduated projects to be at v1.0 or above?

I know this is easily gamed, in the sense that project maintainers can release any version number they like, but let’s set that aside for now and assume that maintainers are well intentioned. I wonder if the signals that are sent by releasing a v1.0 are similar to what Graduation means?

(I have not checked the version numbers of existing graduated projects)

Thoughts?

Liz





--
Quinton Hoole
quinton@hoole.biz






--
Gareth Rushgrove
@garethr

garethr.dev
devopsweekly.com


Re: [VOTE] Open Policy Agent from incubating to graduated

Bartłomiej Płotka
 

+1 nb 💜

Kind Regards,
Bartek Płotka (@bwplotka)


On Thu, 14 Jan 2021 at 21:29, Justin Cormack via lists.cncf.io <justin.cormack=docker.com@...> wrote:
+1 binding

Justin


On Wed, Sep 30, 2020 at 5:02 PM Amye Scavarda Perrin <ascavarda@...> wrote:
The Open Policy Agent project has applied for graduation from incubation to graduated. (https://github.com/cncf/toc/pull/520)

The due diligence document can be found here: https://docs.google.com/document/d/19M5fTpe57rQIMNxawRl5wSWvJUapuzY-CkV4O5pvieU/edit
 
Brendan Burns has called for public comment: https://lists.cncf.io/g/cncf-toc/message/5281

Please vote (+1/0/-1) by replying to this thread.

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

--
Amye Scavarda Perrin | Program Manager | amye@...


Re: [VOTE] Open Policy Agent from incubating to graduated

Justin Cormack
 

+1 binding

Justin


On Wed, Sep 30, 2020 at 5:02 PM Amye Scavarda Perrin <ascavarda@...> wrote:
The Open Policy Agent project has applied for graduation from incubation to graduated. (https://github.com/cncf/toc/pull/520)

The due diligence document can be found here: https://docs.google.com/document/d/19M5fTpe57rQIMNxawRl5wSWvJUapuzY-CkV4O5pvieU/edit
 
Brendan Burns has called for public comment: https://lists.cncf.io/g/cncf-toc/message/5281

Please vote (+1/0/-1) by replying to this thread.

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

--
Amye Scavarda Perrin | Program Manager | amye@...


Re: [EXTERNAL] [cncf-toc] What do we mean by “Version 1.0”?

Alena Prokharchyk
 

I agree that it should be about setting the bar for the release management, API backwards compatibility, clearly defined versioning scheme and communications around it in Gradulation requirements. Rather than prescribing and generalizing on the SemVer use across the projects. We can put it as a recommendation though. 

-alena.

On Jan 14, 2021, at 11:25 AM, Matt Farina <matt@...> wrote:

I think there is some nuance in here but it's worth discussing.

For example, if a project is using SemVer there are a couple parts of the spec that come to mind...

4. Major version zero (0.y.z) is for initial development.

If a project doesn't have a 1.0.0 yet and it's using SemVer than I don't think it should be graduated because it's still in initial development.

I realize different people do different things with versions. But, versions are about communication. Graduated projects should be clear on their communication of versions.

1. Software using Semantic Versioning MUST declare a public API.

and

8. Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API.

and on the CNCF projects page it talks about Graduated Projects being for the majority. They aren't experiments but things that more cautious businesses can adopt.

A graduated project should state what it's API is (network, library interface, UI output, etc) and then properly version that so that consumers can know what they are getting and when things will change.

These are policy based and different projects can do different things. For example, Kubernetes does not follow SemVer but does specify what is in the supported API policy and how it changes. Helm does something similar with the Go API and output from helm commands. For example, on Helm we have one place where the date format is different from the rest in the output but we can't change that until Helm v4 as a default because we know external tools parse that output.

I would expect graduated projects to do things in a way that communicates clearly on what's happening with versions and have stable releases.

Just my 2 cents.

- Matt Farina

On Thu, Jan 14, 2021, at 1:33 PM, alexis richardson wrote:
IMO, everyone's using version numbers in different ways now.  For example many projects go to 1.0 once they are feature complete, and hit production way before that.  I think insisting on 1.0 for graduation is unfair and not very helpful.

I realise that many enterprise users still see 1.0 as being the first production ready version.  Much as Quinton says.

So, I suggest we leave everything as it is, and make sure that our own graduation criteria are clear.



On Thu, 14 Jan 2021, 18:27 Quinton Hoole, <quinton@...> wrote:
I'm not convinced that in people's minds, or practically, v1.0 and Graduated mean similar things. As a concrete example, Kubernetes went to v 1.0 several years before it graduated.  In my mind, version numbers tend to denote the maturity of the software. Graduation levels add to that the maturity of the process and community around the software.

I do however think that there would be value striving for some amount of consistency in the semantics of version numbering across CNCF projects (possibly) to avoid the kind of confusion that Liz ran into.  I don't know exactly what that would look like, but I imagine something along the lines of:

- pre 1.0 denotes "not recommended for production use"
- post x.y denotes "go for it, people are starting to use it successfully in production"
- post p.q denotes "rock solid, widely used in production - almost definitely graduated unless there are extenuating circumstances"

... and so on might make sense.

This detail may well have been debated in depth elsewhere in the CNCF, in which case I apologise for not being up to speed on that :-)

Q
  

On Thu, Jan 14, 2021 at 9:50 AM Michelle Noorali via lists.cncf.io <michelle.noorali=microsoft.com@...> wrote:
+1 imo a graduated project should have some documented backward compatibility guarantees and semantic versioning helps denote this. It has been a best practice on all the projects I've worked on. I'd be supportive of adding a criteria around stability and defining what that means and recommending using a semantic version to denote this for graduation.



From: cncf-toc@... <cncf-toc@...> on behalf of Liz Rice via lists.cncf.io <liz=lizrice.com@...>
Sent: Thursday, January 14, 2021 12:26 PM
To: cncf-toc@... <cncf-toc@...>
Subject: [EXTERNAL] [cncf-toc] What do we mean by “Version 1.0”?
 
Hi folks,  

Someone I spoke with today said something along the lines “if <this project> is stable, why is it still at v0.something?” and that got me thinking - does it make any sense to expect Graduated projects to be at v1.0 or above? 

I know this is easily gamed, in the sense that project maintainers can release any version number they like, but let’s set that aside for now and assume that maintainers are well intentioned. I wonder if the signals that are sent by releasing a v1.0 are similar to what Graduation means?

(I have not checked the version numbers of existing graduated projects)

Thoughts?

Liz





-- 
Quinton Hoole






Re: [EXTERNAL] [cncf-toc] What do we mean by “Version 1.0”?

Matt Farina
 

I think there is some nuance in here but it's worth discussing.

For example, if a project is using SemVer there are a couple parts of the spec that come to mind...

4. Major version zero (0.y.z) is for initial development.

If a project doesn't have a 1.0.0 yet and it's using SemVer than I don't think it should be graduated because it's still in initial development.

I realize different people do different things with versions. But, versions are about communication. Graduated projects should be clear on their communication of versions.

1. Software using Semantic Versioning MUST declare a public API.

and

8. Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API.

and on the CNCF projects page it talks about Graduated Projects being for the majority. They aren't experiments but things that more cautious businesses can adopt.

A graduated project should state what it's API is (network, library interface, UI output, etc) and then properly version that so that consumers can know what they are getting and when things will change.

These are policy based and different projects can do different things. For example, Kubernetes does not follow SemVer but does specify what is in the supported API policy and how it changes. Helm does something similar with the Go API and output from helm commands. For example, on Helm we have one place where the date format is different from the rest in the output but we can't change that until Helm v4 as a default because we know external tools parse that output.

I would expect graduated projects to do things in a way that communicates clearly on what's happening with versions and have stable releases.

Just my 2 cents.

- Matt Farina

On Thu, Jan 14, 2021, at 1:33 PM, alexis richardson wrote:
IMO, everyone's using version numbers in different ways now.  For example many projects go to 1.0 once they are feature complete, and hit production way before that.  I think insisting on 1.0 for graduation is unfair and not very helpful.

I realise that many enterprise users still see 1.0 as being the first production ready version.  Much as Quinton says.

So, I suggest we leave everything as it is, and make sure that our own graduation criteria are clear.



On Thu, 14 Jan 2021, 18:27 Quinton Hoole, <quinton@...> wrote:
I'm not convinced that in people's minds, or practically, v1.0 and Graduated mean similar things. As a concrete example, Kubernetes went to v 1.0 several years before it graduated.  In my mind, version numbers tend to denote the maturity of the software. Graduation levels add to that the maturity of the process and community around the software.

I do however think that there would be value striving for some amount of consistency in the semantics of version numbering across CNCF projects (possibly) to avoid the kind of confusion that Liz ran into.  I don't know exactly what that would look like, but I imagine something along the lines of:

- pre 1.0 denotes "not recommended for production use"
- post x.y denotes "go for it, people are starting to use it successfully in production"
- post p.q denotes "rock solid, widely used in production - almost definitely graduated unless there are extenuating circumstances"

... and so on might make sense.

This detail may well have been debated in depth elsewhere in the CNCF, in which case I apologise for not being up to speed on that :-)

Q
  

On Thu, Jan 14, 2021 at 9:50 AM Michelle Noorali via lists.cncf.io <michelle.noorali=microsoft.com@...> wrote:
+1 imo a graduated project should have some documented backward compatibility guarantees and semantic versioning helps denote this. It has been a best practice on all the projects I've worked on. I'd be supportive of adding a criteria around stability and defining what that means and recommending using a semantic version to denote this for graduation.



From: cncf-toc@... <cncf-toc@...> on behalf of Liz Rice via lists.cncf.io <liz=lizrice.com@...>
Sent: Thursday, January 14, 2021 12:26 PM
To: cncf-toc@... <cncf-toc@...>
Subject: [EXTERNAL] [cncf-toc] What do we mean by “Version 1.0”?
 
Hi folks, 

Someone I spoke with today said something along the lines “if <this project> is stable, why is it still at v0.something?” and that got me thinking - does it make any sense to expect Graduated projects to be at v1.0 or above? 

I know this is easily gamed, in the sense that project maintainers can release any version number they like, but let’s set that aside for now and assume that maintainers are well intentioned. I wonder if the signals that are sent by releasing a v1.0 are similar to what Graduation means?

(I have not checked the version numbers of existing graduated projects)

Thoughts?

Liz





--
Quinton Hoole





Re: [EXTERNAL] [cncf-toc] What do we mean by “Version 1.0”?

alexis richardson
 

IMO, everyone's using version numbers in different ways now.  For example many projects go to 1.0 once they are feature complete, and hit production way before that.  I think insisting on 1.0 for graduation is unfair and not very helpful.

I realise that many enterprise users still see 1.0 as being the first production ready version.  Much as Quinton says.

So, I suggest we leave everything as it is, and make sure that our own graduation criteria are clear.



On Thu, 14 Jan 2021, 18:27 Quinton Hoole, <quinton@...> wrote:
I'm not convinced that in people's minds, or practically, v1.0 and Graduated mean similar things. As a concrete example, Kubernetes went to v 1.0 several years before it graduated.  In my mind, version numbers tend to denote the maturity of the software. Graduation levels add to that the maturity of the process and community around the software.

I do however think that there would be value striving for some amount of consistency in the semantics of version numbering across CNCF projects (possibly) to avoid the kind of confusion that Liz ran into.  I don't know exactly what that would look like, but I imagine something along the lines of:

- pre 1.0 denotes "not recommended for production use"
- post x.y denotes "go for it, people are starting to use it successfully in production"
- post p.q denotes "rock solid, widely used in production - almost definitely graduated unless there are extenuating circumstances"

... and so on might make sense.

This detail may well have been debated in depth elsewhere in the CNCF, in which case I apologise for not being up to speed on that :-)

Q
  

On Thu, Jan 14, 2021 at 9:50 AM Michelle Noorali via lists.cncf.io <michelle.noorali=microsoft.com@...> wrote:
+1 imo a graduated project should have some documented backward compatibility guarantees and semantic versioning helps denote this. It has been a best practice on all the projects I've worked on. I'd be supportive of adding a criteria around stability and defining what that means and recommending using a semantic version to denote this for graduation.

From: cncf-toc@... <cncf-toc@...> on behalf of Liz Rice via lists.cncf.io <liz=lizrice.com@...>
Sent: Thursday, January 14, 2021 12:26 PM
To: cncf-toc@... <cncf-toc@...>
Subject: [EXTERNAL] [cncf-toc] What do we mean by “Version 1.0”?
 
Hi folks, 

Someone I spoke with today said something along the lines “if <this project> is stable, why is it still at v0.something?” and that got me thinking - does it make any sense to expect Graduated projects to be at v1.0 or above? 

I know this is easily gamed, in the sense that project maintainers can release any version number they like, but let’s set that aside for now and assume that maintainers are well intentioned. I wonder if the signals that are sent by releasing a v1.0 are similar to what Graduation means?

(I have not checked the version numbers of existing graduated projects)

Thoughts?

Liz



--
Quinton Hoole
quinton@...


Re: [EXTERNAL] [cncf-toc] What do we mean by “Version 1.0”?

Quinton Hoole <quinton@...>
 

I'm not convinced that in people's minds, or practically, v1.0 and Graduated mean similar things. As a concrete example, Kubernetes went to v 1.0 several years before it graduated.  In my mind, version numbers tend to denote the maturity of the software. Graduation levels add to that the maturity of the process and community around the software.

I do however think that there would be value striving for some amount of consistency in the semantics of version numbering across CNCF projects (possibly) to avoid the kind of confusion that Liz ran into.  I don't know exactly what that would look like, but I imagine something along the lines of:

- pre 1.0 denotes "not recommended for production use"
- post x.y denotes "go for it, people are starting to use it successfully in production"
- post p.q denotes "rock solid, widely used in production - almost definitely graduated unless there are extenuating circumstances"

... and so on might make sense.

This detail may well have been debated in depth elsewhere in the CNCF, in which case I apologise for not being up to speed on that :-)

Q
  

On Thu, Jan 14, 2021 at 9:50 AM Michelle Noorali via lists.cncf.io <michelle.noorali=microsoft.com@...> wrote:
+1 imo a graduated project should have some documented backward compatibility guarantees and semantic versioning helps denote this. It has been a best practice on all the projects I've worked on. I'd be supportive of adding a criteria around stability and defining what that means and recommending using a semantic version to denote this for graduation.

From: cncf-toc@... <cncf-toc@...> on behalf of Liz Rice via lists.cncf.io <liz=lizrice.com@...>
Sent: Thursday, January 14, 2021 12:26 PM
To: cncf-toc@... <cncf-toc@...>
Subject: [EXTERNAL] [cncf-toc] What do we mean by “Version 1.0”?
 
Hi folks, 

Someone I spoke with today said something along the lines “if <this project> is stable, why is it still at v0.something?” and that got me thinking - does it make any sense to expect Graduated projects to be at v1.0 or above? 

I know this is easily gamed, in the sense that project maintainers can release any version number they like, but let’s set that aside for now and assume that maintainers are well intentioned. I wonder if the signals that are sent by releasing a v1.0 are similar to what Graduation means?

(I have not checked the version numbers of existing graduated projects)

Thoughts?

Liz



--
Quinton Hoole
quinton@...


Re: [EXTERNAL] [cncf-toc] What do we mean by “Version 1.0”?

Michelle Noorali
 

+1 imo a graduated project should have some documented backward compatibility guarantees and semantic versioning helps denote this. It has been a best practice on all the projects I've worked on. I'd be supportive of adding a criteria around stability and defining what that means and recommending using a semantic version to denote this for graduation.


From: cncf-toc@... <cncf-toc@...> on behalf of Liz Rice via lists.cncf.io <liz=lizrice.com@...>
Sent: Thursday, January 14, 2021 12:26 PM
To: cncf-toc@... <cncf-toc@...>
Subject: [EXTERNAL] [cncf-toc] What do we mean by “Version 1.0”?
 
Hi folks, 

Someone I spoke with today said something along the lines “if <this project> is stable, why is it still at v0.something?” and that got me thinking - does it make any sense to expect Graduated projects to be at v1.0 or above? 

I know this is easily gamed, in the sense that project maintainers can release any version number they like, but let’s set that aside for now and assume that maintainers are well intentioned. I wonder if the signals that are sent by releasing a v1.0 are similar to what Graduation means?

(I have not checked the version numbers of existing graduated projects)

Thoughts?

Liz


What do we mean by “Version 1.0”?

Liz Rice
 

Hi folks, 

Someone I spoke with today said something along the lines “if <this project> is stable, why is it still at v0.something?” and that got me thinking - does it make any sense to expect Graduated projects to be at v1.0 or above? 

I know this is easily gamed, in the sense that project maintainers can release any version number they like, but let’s set that aside for now and assume that maintainers are well intentioned. I wonder if the signals that are sent by releasing a v1.0 are similar to what Graduation means?

(I have not checked the version numbers of existing graduated projects)

Thoughts?

Liz


Re: SIG-Security Tech Lead nominations

Amye Scavarda Perrin
 

On Thu, Dec 17, 2020 at 5:43 PM Jeyappragash Jeyakeerthi <jj@...> wrote:

Dear Technical Oversight Committee,


On December 16th 2020, the SIG-Security co-chairs along with then TOC liason’s Liz Rice and Justin Cormack, agreed to nominate three Tech Leads for SIG-Security: Ashutosh Narkar, Aradhana Chetal and Andres Vega.


“Tech leads are assigned following a 2/3 majority vote of the TOC and a 2/3 majority vote of SIG Chairs” — cncf-sig elections


Thank you!

Jeyappragash.J.J

(On behalf of SIG-Security Chairs)


TL Candidates - Dec 2020


Ashutosh Narkar 


Aradhana Chetal 


Andres Vega

  • SIG-Security highlights

  • Professional affiliations: 

    • VMWare

  • Github: @anvega

  • CNCF Projects:

    • SPIFFE/SPIRE

  • SIG-Security 

    • Security Assess. Review lead: Harbor

    • Security Assess. Review lead: Cloud Buildpaks

    • Security Assess. participant: SPIFFE/SPIRE

    • Security Day program committee 2020 NA

    • Facilitator for SIG meetings, and in general good with making calls more lively (1)

    • Participating in organization of CN Sec. Day 2021 EU

    • Commits (5)

    • Issues (13)





--
Amye Scavarda Perrin | Program Manager | amye@...


Re: SIG-Security Tech Lead nominations

Magno Logan
 

+1 NB

Best Regards,

Magno Logan


On Thu, Jan 7, 2021 at 3:55 PM Matt Klein <mattklein123@...> wrote:
+1 binding

On Thu, Dec 17, 2020 at 5:43 PM Jeyappragash Jeyakeerthi <jj@...> wrote:

Dear Technical Oversight Committee,


On December 16th 2020, the SIG-Security co-chairs along with then TOC liason’s Liz Rice and Justin Cormack, agreed to nominate three Tech Leads for SIG-Security: Ashutosh Narkar, Aradhana Chetal and Andres Vega.


“Tech leads are assigned following a 2/3 majority vote of the TOC and a 2/3 majority vote of SIG Chairs” — cncf-sig elections


Thank you!

Jeyappragash.J.J

(On behalf of SIG-Security Chairs)


TL Candidates - Dec 2020


Ashutosh Narkar 


Aradhana Chetal 


Andres Vega

  • SIG-Security highlights

  • Professional affiliations: 

    • VMWare

  • Github: @anvega

  • CNCF Projects:

    • SPIFFE/SPIRE

  • SIG-Security 

    • Security Assess. Review lead: Harbor

    • Security Assess. Review lead: Cloud Buildpaks

    • Security Assess. participant: SPIFFE/SPIRE

    • Security Day program committee 2020 NA

    • Facilitator for SIG meetings, and in general good with making calls more lively (1)

    • Participating in organization of CN Sec. Day 2021 EU

    • Commits (5)

    • Issues (13)



781 - 800 of 6392