TSC@lists.opendaylight.org | draft lithium release plan

Colin Dixon

#1960

The draft release plan that Phil and I have been working on is ready for comments. You can find it here:
https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckd

Some highlights:

* We use offsets with a delay of 2 between offsets for code deliverables

* Documentation, Integration, and Test are called out more explicitly and earlier

* Most of the lessons learned section is addressed with notes as to how [0]

Huge thanks to Phil for his help in this.

I've put a significant block of time aside on the agenda for the TSC call to go through it as well, but it's probably worth reading through before then as well.

Thanks,

--Colin

[0] https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckd#Lessons_from_Hydrogen.2FHelium_that_Should_be_Applied

Abhijit Kumbhare

#1961

This looks a lot better to me.

Show quoted text

On Wed, Oct 22, 2014 at 5:14 PM, Colin Dixon <colin@...> wrote:

The draft release plan that Phil and I have been working on is ready for comments. You can find it here:
https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckd

Some highlights:
* We use offsets with a delay of 2 between offsets for code deliverables
* Documentation, Integration, and Test are called out more explicitly and earlier
* Most of the lessons learned section is addressed with notes as to how [0]

Huge thanks to Phil for his help in this.

I've put a significant block of time aside on the agenda for the TSC call to go through it as well, but it's probably worth reading through before then as well.

Thanks,
--Colin

[0] https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckd#Lessons_from_Hydrogen.2FHelium_that_Should_be_Applied

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

Chris Price <chrispriceab@...>

#1964

Hi Colin & Phil,

Really nice updates.

It provides a more comprehensible reference for projects who will be involved in a project.

Small point of comment from me.

I can understand why you have spent some time defining the project lead role in this document, however I would prefer if we were able to articulate in the context of a project the role of the project leader for projects to be better able to nominate the right person. The RC document can then focus on describing the expectations on the PL for the release.

Just a point of note, and maybe not an urgent one, but as we are about to implement the role of “project lead” in ODL it should likely be done as an activity of it’s own to some extent. (The PL really serves the project itself rather than the release process)

Also not sure about the “SR contact” role. It states most projects will use the project lead for this, which projects might not do that and why would that be the case? Is this a delegate of the PL?

All in all thought well done both of you! Fantastic improvements.

/ Chris

From: Colin Dixon <colin@...>
Date: Thursday 23 October 2014 02:14
To: "tsc@..." <tsc@...>
Subject: [OpenDaylight TSC] draft lithium release plan

The draft release plan that Phil and I have been working on is ready for comments. You can find it here:
https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckd

Some highlights:

* We use offsets with a delay of 2 between offsets for code deliverables

* Documentation, Integration, and Test are called out more explicitly and earlier

* Most of the lessons learned section is addressed with notes as to how [0]

Huge thanks to Phil for his help in this.

I've put a significant block of time aside on the agenda for the TSC call to go through it as well, but it's probably worth reading through before then as well.

Thanks,

--Colin

[0] https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckd#Lessons_from_Hydrogen.2FHelium_that_Should_be_Applied

_______________________________________________ TSC mailing list TSC@... https://lists.opendaylight.org/mailman/listinfo/tsc

Colin Dixon

#1966

Inline.

On Thu, Oct 23, 2014 at 3:44 AM, Chris Price <chrispriceab@...> wrote:

Hi Colin & Phil,

Really nice updates.
It provides a more comprehensible reference for projects who will be involved in a project.

Small point of comment from me.
I can understand why you have spent some time defining the project lead role in this document, however I would prefer if we were able to articulate in the context of a project the role of the project leader for projects to be better able to nominate the right person. The RC document can then focus on describing the expectations on the PL for the release.
Just a point of note, and maybe not an urgent one, but as we are about to implement the role of “project lead” in ODL it should likely be done as an activity of it’s own to some extent. (The PL really serves the project itself rather than the release process)

I agree and I'd really like to stress that the PL role is one of responsibility and actual getting things done, not just a title. I think we start do some of that here, and the TSC can do more to help defining that going forward.

Also not sure about the “SR contact” role. It states most projects will use the project lead for this, which projects might not do that and why would that be the case? Is this a delegate of the PL?

I agree, the intent was to have the roles be one in the same in most cases. There needs to be a mechanism to delegate (at least for a period of time) and we described that at the top.

All in all thought well done both of you! Fantastic improvements.

/ Chris

From: Colin Dixon <colin@...>
Date: Thursday 23 October 2014 02:14
To: "tsc@..." <tsc@...>
Subject: [OpenDaylight TSC] draft lithium release plan

The draft release plan that Phil and I have been working on is ready for comments. You can find it here:
https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckd

Some highlights:
* We use offsets with a delay of 2 between offsets for code deliverables
* Documentation, Integration, and Test are called out more explicitly and earlier
* Most of the lessons learned section is addressed with notes as to how [0]

Huge thanks to Phil for his help in this.

I've put a significant block of time aside on the agenda for the TSC call to go through it as well, but it's probably worth reading through before then as well.

Thanks,
--Colin

[0] https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckd#Lessons_from_Hydrogen.2FHelium_that_Should_be_Applied

_______________________________________________ TSC mailing list TSC@... https://lists.opendaylight.org/mailman/listinfo/tsc

Luis Gomez

#1969

First, thanks for putting this plan all together, this is so far the best release plan I have seen in ODL.

Second, just a proposal after the TSC call today: if we expect community to push back/argue some of the integration & system test & documentation requirements published by M2, I would add an event in M1 that will be for Integration & Documentation to publish a requirements candidate so that we can start discussion already there and fix the requirements by M2.

BR/Luis

Show quoted text

On Oct 23, 2014, at 9:00 AM, Colin Dixon <colin@...> wrote:

Inline.

On Thu, Oct 23, 2014 at 3:44 AM, Chris Price <chrispriceab@...> wrote:
Hi Colin & Phil,

Really nice updates.
It provides a more comprehensible reference for projects who will be involved in a project.

Small point of comment from me.
I can understand why you have spent some time defining the project lead role in this document, however I would prefer if we were able to articulate in the context of a project the role of the project leader for projects to be better able to nominate the right person. The RC document can then focus on describing the expectations on the PL for the release.
Just a point of note, and maybe not an urgent one, but as we are about to implement the role of “project lead” in ODL it should likely be done as an activity of it’s own to some extent. (The PL really serves the project itself rather than the release process)

I agree and I'd really like to stress that the PL role is one of responsibility and actual getting things done, not just a title. I think we start do some of that here, and the TSC can do more to help defining that going forward.

Also not sure about the “SR contact” role. It states most projects will use the project lead for this, which projects might not do that and why would that be the case? Is this a delegate of the PL?

I agree, the intent was to have the roles be one in the same in most cases. There needs to be a mechanism to delegate (at least for a period of time) and we described that at the top.

All in all thought well done both of you! Fantastic improvements.

/ Chris

From: Colin Dixon <colin@...>
Date: Thursday 23 October 2014 02:14
To: "tsc@..." <tsc@...>
Subject: [OpenDaylight TSC] draft lithium release plan

The draft release plan that Phil and I have been working on is ready for comments. You can find it here:
https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckd

Some highlights:
* We use offsets with a delay of 2 between offsets for code deliverables
* Documentation, Integration, and Test are called out more explicitly and earlier
* Most of the lessons learned section is addressed with notes as to how [0]

Huge thanks to Phil for his help in this.

I've put a significant block of time aside on the agenda for the TSC call to go through it as well, but it's probably worth reading through before then as well.

Thanks,
--Colin

[0]https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckd#Lessons_from_Hydrogen.2FHelium_that_Should_be_Applied

_______________________________________________ TSC mailing list TSC@...https://lists.opendaylight.org/mailman/listinfo/tsc

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

Pugh, Rex <rex.pugh@...>

#1975

Great Release plan work. We are especially pleased with the increased requirements around quality.

5. Quality

No later than M2 as part of the Gerrit/Jenkins merge process participating projects must push their binary artifacts to the Nexus repository
No later than M2, each project must have a Jenkins Job which rebuilds and retests to an appropriate level when a project it depends on publishes new artifacts
No later than M2, each project primarily written in Java must be reporting unit test coverage via sonar

How far can we push? Can we also institute that each project require an acceptance test or unit test suite run as part of any Gerrit checkin and publishing of new artifacts. Openstack does this.

Rex

From: tsc-bounces@... [mailto:tsc-bounces@...] On Behalf Of Luis Gomez

Show quoted text

Sent: Thursday, October 23, 2014 12:11 PM
To: Colin Dixon
Cc: tsc@...
Subject: Re: [OpenDaylight TSC] draft lithium release plan

First, thanks for putting this plan all together, this is so far the best release plan I have seen in ODL.

Second, just a proposal after the TSC call today: if we expect community to push back/argue some of the integration & system test & documentation requirements published by M2, I would add an event in M1 that will be for Integration & Documentation to publish a requirements candidate so that we can start discussion already there and fix the requirements by M2.

BR/Luis

On Oct 23, 2014, at 9:00 AM, Colin Dixon <colin@...> wrote:

Inline.

On Thu, Oct 23, 2014 at 3:44 AM, Chris Price <chrispriceab@...> wrote:

Hi Colin & Phil,

Really nice updates.

It provides a more comprehensible reference for projects who will be involved in a project.

Small point of comment from me.

I can understand why you have spent some time defining the project lead role in this document, however I would prefer if we were able to articulate in the context of a project the role of the project leader for projects to be better able to nominate the right person. The RC document can then focus on describing the expectations on the PL for the release.

Just a point of note, and maybe not an urgent one, but as we are about to implement the role of “project lead” in ODL it should likely be done as an activity of it’s own to some extent. (The PL really serves the project itself rather than the release process)

I agree and I'd really like to stress that the PL role is one of responsibility and actual getting things done, not just a title. I think we start do some of that here, and the TSC can do more to help defining that going forward.

Also not sure about the “SR contact” role. It states most projects will use the project lead for this, which projects might not do that and why would that be the case? Is this a delegate of the PL?

I agree, the intent was to have the roles be one in the same in most cases. There needs to be a mechanism to delegate (at least for a period of time) and we described that at the top.

All in all thought well done both of you! Fantastic improvements.

/ Chris

From: Colin Dixon <colin@...>
Date: Thursday 23 October 2014 02:14
To: "tsc@..." <tsc@...>
Subject: [OpenDaylight TSC] draft lithium release plan

The draft release plan that Phil and I have been working on is ready for comments. You can find it here:
https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckd

Some highlights:

* We use offsets with a delay of 2 between offsets for code deliverables

* Documentation, Integration, and Test are called out more explicitly and earlier

* Most of the lessons learned section is addressed with notes as to how [0]

Huge thanks to Phil for his help in this.

I've put a significant block of time aside on the agenda for the TSC call to go through it as well, but it's probably worth reading through before then as well.

Thanks,

--Colin

[0]https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckd#Lessons_from_Hydrogen.2FHelium_that_Should_be_Applied

_______________________________________________ TSC mailing list TSC@...https://lists.opendaylight.org/mailman/listinfo/tsc

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

Luis Gomez

#1974

Actually thinking this more, we should get all integration & system test & documentation requirements decided and published by M1 so projects can incorporate those in their release plan candidates.

BR/Luis

Show quoted text

On Oct 23, 2014, at 12:11 PM, Luis Gomez <ecelgp@...> wrote:

First, thanks for putting this plan all together, this is so far the best release plan I have seen in ODL.

Second, just a proposal after the TSC call today: if we expect community to push back/argue some of the integration & system test & documentation requirements published by M2, I would add an event in M1 that will be for Integration & Documentation to publish a requirements candidate so that we can start discussion already there and fix the requirements by M2.

BR/Luis

On Oct 23, 2014, at 9:00 AM, Colin Dixon <colin@...> wrote:

Inline.

On Thu, Oct 23, 2014 at 3:44 AM, Chris Price <chrispriceab@...> wrote:
Hi Colin & Phil,

Really nice updates.
It provides a more comprehensible reference for projects who will be involved in a project.

Small point of comment from me.
I can understand why you have spent some time defining the project lead role in this document, however I would prefer if we were able to articulate in the context of a project the role of the project leader for projects to be better able to nominate the right person. The RC document can then focus on describing the expectations on the PL for the release.
Just a point of note, and maybe not an urgent one, but as we are about to implement the role of “project lead” in ODL it should likely be done as an activity of it’s own to some extent. (The PL really serves the project itself rather than the release process)

I agree and I'd really like to stress that the PL role is one of responsibility and actual getting things done, not just a title. I think we start do some of that here, and the TSC can do more to help defining that going forward.

Also not sure about the “SR contact” role. It states most projects will use the project lead for this, which projects might not do that and why would that be the case? Is this a delegate of the PL?

I agree, the intent was to have the roles be one in the same in most cases. There needs to be a mechanism to delegate (at least for a period of time) and we described that at the top.

All in all thought well done both of you! Fantastic improvements.

/ Chris

From: Colin Dixon <colin@...>
Date: Thursday 23 October 2014 02:14
To: "tsc@..." <tsc@...>
Subject: [OpenDaylight TSC] draft lithium release plan

The draft release plan that Phil and I have been working on is ready for comments. You can find it here:
https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckd

Some highlights:
* We use offsets with a delay of 2 between offsets for code deliverables
* Documentation, Integration, and Test are called out more explicitly and earlier
* Most of the lessons learned section is addressed with notes as to how [0]

Huge thanks to Phil for his help in this.

I've put a significant block of time aside on the agenda for the TSC call to go through it as well, but it's probably worth reading through before then as well.

Thanks,
--Colin

[0]https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckd#Lessons_from_Hydrogen.2FHelium_that_Should_be_Applied

_______________________________________________ TSC mailing list TSC@...https://lists.opendaylight.org/mailman/listinfo/tsc

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

Luis Gomez

#1977

Hi Rex,

Junit and PAX-EXAM tests run already as part of gerrit checkin (verify job) and gerrit merge (merge jobs) events. You can see the CI process here:

https://wiki.opendaylight.org/view/OpenDaylight_Controller:Development_Infrastructure_Overview

The only thing missing is we do not know how good or bad are these java tests and that is why we would like to have all projects reporting to Sonar.

BR/Luis

Show quoted text

On Oct 23, 2014, at 5:01 PM, Pugh, Rex <rex.pugh@...> wrote:

Great Release plan work. We are especially pleased with the increased requirements around quality.
5. Quality
No later than M2 as part of the Gerrit/Jenkins merge process participating projects must push their binary artifacts to the Nexus repository
No later than M2, each project must have a Jenkins Job which rebuilds and retests to an appropriate level when a project it depends on publishes new artifacts
No later than M2, each project primarily written in Java must be reporting unit test coverage via sonar
How far can we push? Can we also institute that each project require an acceptance test or unit test suite run as part of any Gerrit checkin and publishing of new artifacts. Openstack does this.
Rex

From: tsc-bounces@... [mailto:tsc-bounces@...] On Behalf Of Luis Gomez
Sent: Thursday, October 23, 2014 12:11 PM
To: Colin Dixon
Cc: tsc@...
Subject: Re: [OpenDaylight TSC] draft lithium release plan

First, thanks for putting this plan all together, this is so far the best release plan I have seen in ODL.

Second, just a proposal after the TSC call today: if we expect community to push back/argue some of the integration & system test & documentation requirements published by M2, I would add an event in M1 that will be for Integration & Documentation to publish a requirements candidate so that we can start discussion already there and fix the requirements by M2.

BR/Luis

On Oct 23, 2014, at 9:00 AM, Colin Dixon <colin@...> wrote:

Inline.

On Thu, Oct 23, 2014 at 3:44 AM, Chris Price <chrispriceab@...> wrote:
Hi Colin & Phil,

Really nice updates.
It provides a more comprehensible reference for projects who will be involved in a project.

Small point of comment from me.
I can understand why you have spent some time defining the project lead role in this document, however I would prefer if we were able to articulate in the context of a project the role of the project leader for projects to be better able to nominate the right person. The RC document can then focus on describing the expectations on the PL for the release.
Just a point of note, and maybe not an urgent one, but as we are about to implement the role of “project lead” in ODL it should likely be done as an activity of it’s own to some extent. (The PL really serves the project itself rather than the release process)

I agree and I'd really like to stress that the PL role is one of responsibility and actual getting things done, not just a title. I think we start do some of that here, and the TSC can do more to help defining that going forward.
Also not sure about the “SR contact” role. It states most projects will use the project lead for this, which projects might not do that and why would that be the case? Is this a delegate of the PL?

I agree, the intent was to have the roles be one in the same in most cases. There needs to be a mechanism to delegate (at least for a period of time) and we described that at the top.

All in all thought well done both of you! Fantastic improvements.

/ Chris

From: Colin Dixon <colin@...>
Date: Thursday 23 October 2014 02:14
To: "tsc@..." <tsc@...>
Subject: [OpenDaylight TSC] draft lithium release plan

The draft release plan that Phil and I have been working on is ready for comments. You can find it here:
https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckd
Some highlights:
* We use offsets with a delay of 2 between offsets for code deliverables
* Documentation, Integration, and Test are called out more explicitly and earlier
* Most of the lessons learned section is addressed with notes as to how [0]
Huge thanks to Phil for his help in this.

I've put a significant block of time aside on the agenda for the TSC call to go through it as well, but it's probably worth reading through before then as well.

Thanks,
--Colin

[0]https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckd#Lessons_from_Hydrogen.2FHelium_that_Should_be_Applied

_______________________________________________ TSC mailing list TSC@...https://lists.opendaylight.org/mailman/listinfo/tsc

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

Pugh, Rex <rex.pugh@...>

#1981

Ah Thanks Luis. Excellent.

Rex

Show quoted text

From: Luis Gomez [mailto:ecelgp@...]
Sent: Thursday, October 23, 2014 7:46 PM
To: Pugh, Rex
Cc: Tassinari, Mark A; Porter, Kevin L (HP Networking); tsc@...
Subject: Re: [OpenDaylight TSC] draft lithium release plan

Hi Rex,

Junit and PAX-EXAM tests run already as part of gerrit checkin (verify job) and gerrit merge (merge jobs) events. You can see the CI process here:

https://wiki.opendaylight.org/view/OpenDaylight_Controller:Development_Infrastructure_Overview

The only thing missing is we do not know how good or bad are these java tests and that is why we would like to have all projects reporting to Sonar.

BR/Luis

On Oct 23, 2014, at 5:01 PM, Pugh, Rex <rex.pugh@...> wrote:

Great Release plan work. We are especially pleased with the increased requirements around quality.

5. Quality

No later than M2 as part of the Gerrit/Jenkins merge process participating projects must push their binary artifacts to the Nexus repository
No later than M2, each project must have a Jenkins Job which rebuilds and retests to an appropriate level when a project it depends on publishes new artifacts
No later than M2, each project primarily written in Java must be reporting unit test coverage via sonar

How far can we push? Can we also institute that each project require an acceptance test or unit test suite run as part of any Gerrit checkin and publishing of new artifacts. Openstack does this.

Rex

From: tsc-bounces@... [mailto:tsc-bounces@...] On Behalf Of Luis Gomez
Sent: Thursday, October 23, 2014 12:11 PM
To: Colin Dixon
Cc: tsc@...
Subject: Re: [OpenDaylight TSC] draft lithium release plan

First, thanks for putting this plan all together, this is so far the best release plan I have seen in ODL.

Second, just a proposal after the TSC call today: if we expect community to push back/argue some of the integration & system test & documentation requirements published by M2, I would add an event in M1 that will be for Integration & Documentation to publish a requirements candidate so that we can start discussion already there and fix the requirements by M2.

BR/Luis

On Oct 23, 2014, at 9:00 AM, Colin Dixon <colin@...> wrote:

Inline.

On Thu, Oct 23, 2014 at 3:44 AM, Chris Price <chrispriceab@...> wrote:

Hi Colin & Phil,

Really nice updates.

It provides a more comprehensible reference for projects who will be involved in a project.

Small point of comment from me.

I can understand why you have spent some time defining the project lead role in this document, however I would prefer if we were able to articulate in the context of a project the role of the project leader for projects to be better able to nominate the right person. The RC document can then focus on describing the expectations on the PL for the release.

Just a point of note, and maybe not an urgent one, but as we are about to implement the role of “project lead” in ODL it should likely be done as an activity of it’s own to some extent. (The PL really serves the project itself rather than the release process)

I agree and I'd really like to stress that the PL role is one of responsibility and actual getting things done, not just a title. I think we start do some of that here, and the TSC can do more to help defining that going forward.

Also not sure about the “SR contact” role. It states most projects will use the project lead for this, which projects might not do that and why would that be the case? Is this a delegate of the PL?

I agree, the intent was to have the roles be one in the same in most cases. There needs to be a mechanism to delegate (at least for a period of time) and we described that at the top.

All in all thought well done both of you! Fantastic improvements.

/ Chris

From: Colin Dixon <colin@...>
Date: Thursday 23 October 2014 02:14
To: "tsc@..." <tsc@...>
Subject: [OpenDaylight TSC] draft lithium release plan

The draft release plan that Phil and I have been working on is ready for comments. You can find it here:
https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckd

Some highlights:

* We use offsets with a delay of 2 between offsets for code deliverables

* Documentation, Integration, and Test are called out more explicitly and earlier

* Most of the lessons learned section is addressed with notes as to how [0]

Huge thanks to Phil for his help in this.

I've put a significant block of time aside on the agenda for the TSC call to go through it as well, but it's probably worth reading through before then as well.

Thanks,

--Colin

[0]https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckd#Lessons_from_Hydrogen.2FHelium_that_Should_be_Applied

_______________________________________________ TSC mailing list TSC@...https://lists.opendaylight.org/mailman/listinfo/tsc

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

Chris Wright <chrisw@...>

#1983

* Colin Dixon (colin@...) wrote:
The draft release plan that Phil and I have been working on is ready for
comments. You can find it here:
https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckdI think a Legacy API sounds like something old where there is also a
newer way to do the same thing.  I'd suggest Stable API.

I don't understand this part of Provisional API: 

  "...or an externally accessible API that existed in a previous version
   of ODL but is being modified for the current release."

The part that is unclear to me is the state the API was in during the
previous version.  IOW, to me it _had_ to be Provisional to begin with,
else you couldn't change it.  If it was Legacy (Stable?) to begin with,
then this is a _new_ API, and certainly the new API is Provisional.

Also, I think the APIs should be marked in code, annotations being one
obvious way to do it (in today's call we touched on deprecated, and only
exporting supported APIs)?  The ability to enumerate externally consumable
APIs should be automated, and even better, the API state marked in the
code so that it's clear to the consumer what contract you are receiving.

thanks,
-chris

Robert Varga

#1987

On 10/24/2014 08:49 PM, Chris Wright wrote:
* Colin Dixon (colin@...) wrote:
The draft release plan that Phil and I have been working on is ready for
comments. You can find it here:
https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckdI think a Legacy API sounds like something old where there is also a
newer way to do the same thing.  I'd suggest Stable API.

I don't understand this part of Provisional API:

   "...or an externally accessible API that existed in a previous version
    of ODL but is being modified for the current release."

The part that is unclear to me is the state the API was in during the
previous version.  IOW, to me it _had_ to be Provisional to begin with,
else you couldn't change it.  If it was Legacy (Stable?) to begin with,
then this is a _new_ API, and certainly the new API is Provisional.

Also, I think the APIs should be marked in code, annotations being one
obvious way to do it (in today's call we touched on deprecated, and only
exporting supported APIs)?  The ability to enumerate externally consumable
APIs should be automated, and even better, the API state marked in the
code so that it's clear to the consumer what contract you are receiving.Unfortunately, we have had little consensus on the fact that we should be marking APIs. We currently completely lack the tools to do so in the models, too.

I would hate to associate the word 'stable' with an API. In confers a sense of matureness simply not present in a lot of Helium APIs.

I think clarifying/documenting the API intent in the early stages of this particular release is a good thing, simply because it has not really happened in the last release.

At this point we do not have a clear proposal on how to mark the APIs, much less a proven mechanism. I think that disqualifies it from being mandatory in this release, but yes, we need something going forward. Yangtools has trailblazed with using @Deprecated and @Beta, but the problem is a lot more complicated than that, and most of our code does not even use the visibility modifiers properly -- any taker for writing a guideline?

Bye,
Robert

Robert Varga

#1988

Hello,

We have historically allowed waiver-less additions to APIs, which would presumably be needed for new functionality. Give that are institution functionality freeze before the API freeze, wouldn't it make sense to also gate API additions through the waiver procedure?

Bye,
Robert

On 10/23/2014 02:14 AM, Colin Dixon wrote:

Show quoted text

The draft release plan that Phil and I have been working on is ready for comments. You can find it here:
https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckd

Some highlights:

* We use offsets with a delay of 2 between offsets for code deliverables

* Documentation, Integration, and Test are called out more explicitly and earlier

* Most of the lessons learned section is addressed with notes as to how [0]

Huge thanks to Phil for his help in this.

I've put a significant block of time aside on the agenda for the TSC call to go through it as well, but it's probably worth reading through before then as well.

Thanks,

--Colin

[0] https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckd#Lessons_from_Hydrogen.2FHelium_that_Should_be_Applied
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

Chris Wright <chrisw@...>

#1990

* Robert Varga (nite@...) wrote:
On 10/24/2014 08:49 PM, Chris Wright wrote:
* Colin Dixon (colin@...) wrote:
The draft release plan that Phil and I have been working on is ready for
comments. You can find it here:
https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckdI think a Legacy API sounds like something old where there is also a
newer way to do the same thing.  I'd suggest Stable API.

I don't understand this part of Provisional API:

  "...or an externally accessible API that existed in a previous version
   of ODL but is being modified for the current release."

The part that is unclear to me is the state the API was in during the
previous version.  IOW, to me it _had_ to be Provisional to begin with,
else you couldn't change it.  If it was Legacy (Stable?) to begin with,
then this is a _new_ API, and certainly the new API is Provisional.

Also, I think the APIs should be marked in code, annotations being one
obvious way to do it (in today's call we touched on deprecated, and only
exporting supported APIs)?  The ability to enumerate externally consumable
APIs should be automated, and even better, the API state marked in the
code so that it's clear to the consumer what contract you are receiving.Unfortunately, we have had little consensus on the fact that we should be
marking APIs.I think it's a good idea, what is your opinion?

We currently completely lack the tools to do so in the models, too.Do you think that's an insurmountable issue or more a matter of someone
w/ the time to do this work?  I'm assuming the later given your reference
to @Deprecated and @Beta w/ yangtools.

I would hate to associate the word 'stable' with an API. In confers a sense
of matureness simply not present in a lot of Helium APIs.Hrm, you don't like Stable, I don't like Legacy.  Only other word that
springs to mind is Supported.  I do think Stable conveys the right
message, i.e. it won't change on you.

I think clarifying/documenting the API intent in the early stages of this
particular release is a good thing, simply because it has not really
happened in the last release.Yeah, I agree.

At this point we do not have a clear proposal on how to mark the APIs, much
less a proven mechanism. I think that disqualifies it from being mandatory
in this release, but yes, we need something going forward. Yangtools has
trailblazed with using @Deprecated and @Beta, but the problem is a lot more
complicated than that, and most of our code does not even use the visibility
modifiers properly -- any taker for writing a guideline?To be clear, I'm not suggesting mandatory.  I am suggesting that we
support being clear in the code so that we can enumerate w/out that
being manual (the template requires submitting a list of APIs which
strikes me as a waste of time if we can generate the list), and clearly
show the API status to consumers through annotations, javadoc, etc.

What I've seen in Spark fairly typical annotation def'n:

@Retention(value=RUNTIME)
@Target(value={TYPE,FIELD,METHOD,PARAMETER,CONSTRUCTOR,LOCAL_VARIABLE,PACKAGE})
public @interface Experimental

Would it be useful to have org.opendaylight.annotation?

thanks,
-chris

Rochelle.RochelleGrober <rochelle.grober@...>

#1992

Something learned in OpenStack:

APIs should be versioned. You can always link a name (such as stable, current/deprecated) to a version

OpenStack also only allow backward compatible additions/removals to APIs within the same version. If it breaks a previous release, it needs a new version.

The reason OpenStack is now versioning is so that when there are compatibility breaking changes, the API can be checked programmatically and the right interactions can be provided for the version identified.

Save yourselves a lot of grief and start versioning early!

--Rocky

Show quoted text

From: tsc-bounces@... [mailto:tsc-bounces@...] On Behalf Of Robert Varga
Sent: Friday, October 24, 2014 12:47 PM
To: Colin Dixon; tsc@...
Subject: Re: [OpenDaylight TSC] draft lithium release plan

Hello,

We have historically allowed waiver-less additions to APIs, which would presumably be needed for new functionality. Give that are institution functionality freeze before the API freeze, wouldn't it make sense to also gate API additions through the waiver procedure?

Bye,
Robert

On 10/23/2014 02:14 AM, Colin Dixon wrote:

The draft release plan that Phil and I have been working on is ready for comments. You can find it here:
https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckd

Some highlights:

* We use offsets with a delay of 2 between offsets for code deliverables

* Documentation, Integration, and Test are called out more explicitly and earlier

* Most of the lessons learned section is addressed with notes as to how [0]

Huge thanks to Phil for his help in this.

I've put a significant block of time aside on the agenda for the TSC call to go through it as well, but it's probably worth reading through before then as well.

Thanks,

--Colin

[0] https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckd#Lessons_from_Hydrogen.2FHelium_that_Should_be_Applied
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

Abhijit Kumbhare

#1991

About:

Hrm, you don't like Stable, I don't like Legacy. Only other word that
springs to mind is Supported. I do think Stable conveys the right
message, i.e. it won't change on you.

How about "pre-existing" API?

Show quoted text

On Fri, Oct 24, 2014 at 5:40 PM, Chris Wright <chrisw@...> wrote:

* Robert Varga (nite@...) wrote:
> On 10/24/2014 08:49 PM, Chris Wright wrote:
> >* Colin Dixon (colin@...) wrote:
> >>The draft release plan that Phil and I have been working on is ready for
> >>comments. You can find it here:
> >>https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckd
> >I think a Legacy API sounds like something old where there is also a
> >newer way to do the same thing. I'd suggest Stable API.
> >
> >I don't understand this part of Provisional API:
> >
> > "...or an externally accessible API that existed in a previous version
> > of ODL but is being modified for the current release."
> >
> >The part that is unclear to me is the state the API was in during the
> >previous version. IOW, to me it _had_ to be Provisional to begin with,
> >else you couldn't change it. If it was Legacy (Stable?) to begin with,
> >then this is a _new_ API, and certainly the new API is Provisional.
> >
> >Also, I think the APIs should be marked in code, annotations being one
> >obvious way to do it (in today's call we touched on deprecated, and only
> >exporting supported APIs)? The ability to enumerate externally consumable
> >APIs should be automated, and even better, the API state marked in the
> >code so that it's clear to the consumer what contract you are receiving.
>
> Unfortunately, we have had little consensus on the fact that we should be
> marking APIs.

I think it's a good idea, what is your opinion?

> We currently completely lack the tools to do so in the models, too.

Do you think that's an insurmountable issue or more a matter of someone
w/ the time to do this work? I'm assuming the later given your reference
to @Deprecated and @Beta w/ yangtools.

> I would hate to associate the word 'stable' with an API. In confers a sense
> of matureness simply not present in a lot of Helium APIs.

Hrm, you don't like Stable, I don't like Legacy. Only other word that
springs to mind is Supported. I do think Stable conveys the right
message, i.e. it won't change on you.

> I think clarifying/documenting the API intent in the early stages of this
> particular release is a good thing, simply because it has not really
> happened in the last release.

Yeah, I agree.

> At this point we do not have a clear proposal on how to mark the APIs, much
> less a proven mechanism. I think that disqualifies it from being mandatory
> in this release, but yes, we need something going forward. Yangtools has
> trailblazed with using @Deprecated and @Beta, but the problem is a lot more
> complicated than that, and most of our code does not even use the visibility
> modifiers properly -- any taker for writing a guideline?

To be clear, I'm not suggesting mandatory. I am suggesting that we
support being clear in the code so that we can enumerate w/out that
being manual (the template requires submitting a list of APIs which
strikes me as a waste of time if we can generate the list), and clearly
show the API status to consumers through annotations, javadoc, etc.

What I've seen in Spark fairly typical annotation def'n:

@Retention(value=RUNTIME)
@Target(value={TYPE,FIELD,METHOD,PARAMETER,CONSTRUCTOR,LOCAL_VARIABLE,PACKAGE})
public @interface Experimental

Would it be useful to have org.opendaylight.annotation?

thanks,
-chris

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

Colin Dixon

#1995

The intent was that all new APIs are provisional in their first release. If they're released and not going to change in the next release they'd be legacy or stable in that release. Does that make sense? Is there way we could phrase it better to make that clear?

--Colin

Show quoted text

On Fri, Oct 24, 2014 at 2:49 PM, Chris Wright <chrisw@...> wrote:

I don't understand this part of Provisional API:

"...or an externally accessible API that existed in a previous version
of ODL but is being modified for the current release."

The part that is unclear to me is the state the API was in during the
previous version. IOW, to me it _had_ to be Provisional to begin with,
else you couldn't change it. If it was Legacy (Stable?) to begin with,
then this is a _new_ API, and certainly the new API is Provisional.

Colin Dixon

#1996

I think we have three threads going on:

1.) Not everyone likes the term Legacy and I actually agree with Chris that Stable is a lot better. The definition actually does match that since it says those APIs should remain the same (stable) throughout the release. Supported says bad things about the other APIs that I don't think we want to imply. My vote would be for Stable.

2.) We desperately need tools to help us track APIs, who's using them (across projects) and what state they're in. This is true and I'd love to see us develop some of these tools, perhaps as part of existing/new releng projects.

3.) In the shorter run, I'd really like to see somebody write up simple documentation/tutorials about how people can limit the visibility of their APIs both in pom files and with java keywords.

Exploring using annotations seems like another great idea, but with the exception of @Deprecated, do any of them show up in a visible way for developers? It seems like we'd need a corresponding Eclipse plugin to help most of our developers understand when they were using different kinds of APIs and the expectations they come with.

--Colin

Show quoted text

On Fri, Oct 24, 2014 at 10:13 PM, Abhijit Kumbhare <abhijitkoss@...> wrote:

About:

Hrm, you don't like Stable, I don't like Legacy. Only other word that
springs to mind is Supported. I do think Stable conveys the right
message, i.e. it won't change on you.

How about "pre-existing" API?

On Fri, Oct 24, 2014 at 5:40 PM, Chris Wright <chrisw@...> wrote:
* Robert Varga (nite@...) wrote:
> On 10/24/2014 08:49 PM, Chris Wright wrote:
> >* Colin Dixon (colin@...) wrote:
> >>The draft release plan that Phil and I have been working on is ready for
> >>comments. You can find it here:
> >>https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckd
> >I think a Legacy API sounds like something old where there is also a
> >newer way to do the same thing. I'd suggest Stable API.
> >
> >I don't understand this part of Provisional API:
> >
> > "...or an externally accessible API that existed in a previous version
> > of ODL but is being modified for the current release."
> >
> >The part that is unclear to me is the state the API was in during the
> >previous version. IOW, to me it _had_ to be Provisional to begin with,
> >else you couldn't change it. If it was Legacy (Stable?) to begin with,
> >then this is a _new_ API, and certainly the new API is Provisional.
> >
> >Also, I think the APIs should be marked in code, annotations being one
> >obvious way to do it (in today's call we touched on deprecated, and only
> >exporting supported APIs)? The ability to enumerate externally consumable
> >APIs should be automated, and even better, the API state marked in the
> >code so that it's clear to the consumer what contract you are receiving.
>
> Unfortunately, we have had little consensus on the fact that we should be
> marking APIs.

I think it's a good idea, what is your opinion?

> We currently completely lack the tools to do so in the models, too.

Do you think that's an insurmountable issue or more a matter of someone
w/ the time to do this work? I'm assuming the later given your reference
to @Deprecated and @Beta w/ yangtools.

> I would hate to associate the word 'stable' with an API. In confers a sense
> of matureness simply not present in a lot of Helium APIs.

Hrm, you don't like Stable, I don't like Legacy. Only other word that
springs to mind is Supported. I do think Stable conveys the right
message, i.e. it won't change on you.

> I think clarifying/documenting the API intent in the early stages of this
> particular release is a good thing, simply because it has not really
> happened in the last release.

Yeah, I agree.

> At this point we do not have a clear proposal on how to mark the APIs, much
> less a proven mechanism. I think that disqualifies it from being mandatory
> in this release, but yes, we need something going forward. Yangtools has
> trailblazed with using @Deprecated and @Beta, but the problem is a lot more
> complicated than that, and most of our code does not even use the visibility
> modifiers properly -- any taker for writing a guideline?

To be clear, I'm not suggesting mandatory. I am suggesting that we
support being clear in the code so that we can enumerate w/out that
being manual (the template requires submitting a list of APIs which
strikes me as a waste of time if we can generate the list), and clearly
show the API status to consumers through annotations, javadoc, etc.

What I've seen in Spark fairly typical annotation def'n:

@Retention(value=RUNTIME)
@Target(value={TYPE,FIELD,METHOD,PARAMETER,CONSTRUCTOR,LOCAL_VARIABLE,PACKAGE})
public @interface Experimental

Would it be useful to have org.opendaylight.annotation?

thanks,
-chris

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

Ed Warnicke (eaw) <eaw@...>

#2002

On Oct 24, 2014, at 1:49 PM, Chris Wright <chrisw@...> wrote:

* Colin Dixon (colin@...) wrote:
The draft release plan that Phil and I have been working on is ready for
comments. You can find it here:
https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckdI think a Legacy API sounds like something old where there is also a
newer way to do the same thing.  I'd suggest Stable API.I was thinking something similar, and concur.  To my ear, a legacy API is something we
expect to be deprecating sooner or later (other ears may disagree ;) ).  So I second renaming
Legacy API to Stable API in the plan.

I would also suggest that we need to figure out what the exception process looks like, because there is 
*always* an exception to every rule.  

Further, I would strongly suggest that we adopt a calling out of Legacy(Stable APIs) rather than a 
calling out of Provisional/Tentative APIs.  Unless we are going to essentially force API freeze at M1,
I as a developer have *no* way of knowing what APIs will prove needful as we do development,
so defaulting to Legacy(Stable) makes no sense to me.  It is important to keep in mind that a projects
Release Plan is a statement of what it thinks it will do, not a restriction on what it *can* do.  To treat it otherwise
is to choke innovation.


I don't understand this part of Provisional API: 

 "...or an externally accessible API that existed in a previous version
  of ODL but is being modified for the current release."

The part that is unclear to me is the state the API was in during the
previous version.  IOW, to me it _had_ to be Provisional to begin with,
else you couldn't change it.  If it was Legacy (Stable?) to begin with,
then this is a _new_ API, and certainly the new API is Provisional.

Also, I think the APIs should be marked in code, annotations being one
obvious way to do it (in today's call we touched on deprecated, and only
exporting supported APIs)?  The ability to enumerate externally consumable
APIs should be automated, and even better, the API state marked in the
code so that it's clear to the consumer what contract you are receiving.I strongly concur about marking in code… anyone willing to do a quick annotation?

Ed


thanks,
-chris
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

Ed Warnicke (eaw) <eaw@...>

#2003

So… let me ask this question… can we actually realistically carry out this distinction before we have the

necessary tooling in hand?

Ed

Show quoted text

On Oct 29, 2014, at 10:26 AM, Colin Dixon <colin@...> wrote:

I think we have three threads going on:

1.) Not everyone likes the term Legacy and I actually agree with Chris that Stable is a lot better. The definition actually does match that since it says those APIs should remain the same (stable) throughout the release. Supported says bad things about the other APIs that I don't think we want to imply. My vote would be for Stable.

2.) We desperately need tools to help us track APIs, who's using them (across projects) and what state they're in. This is true and I'd love to see us develop some of these tools, perhaps as part of existing/new releng projects.

3.) In the shorter run, I'd really like to see somebody write up simple documentation/tutorials about how people can limit the visibility of their APIs both in pom files and with java keywords.

Exploring using annotations seems like another great idea, but with the exception of @Deprecated, do any of them show up in a visible way for developers? It seems like we'd need a corresponding Eclipse plugin to help most of our developers understand when they were using different kinds of APIs and the expectations they come with.

--Colin

On Fri, Oct 24, 2014 at 10:13 PM, Abhijit Kumbhare <abhijitkoss@...> wrote:

About:

Hrm, you don't like Stable, I don't like Legacy. Only other word that
springs to mind is Supported. I do think Stable conveys the right
message, i.e. it won't change on you.

How about "pre-existing" API?

On Fri, Oct 24, 2014 at 5:40 PM, Chris Wright <chrisw@...> wrote:

* Robert Varga (nite@...) wrote:
> On 10/24/2014 08:49 PM, Chris Wright wrote:
> >* Colin Dixon (colin@...) wrote:
> >>The draft release plan that Phil and I have been working on is ready for
> >>comments. You can find it here:
> >>https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckd
> >I think a Legacy API sounds like something old where there is also a
> >newer way to do the same thing. I'd suggest Stable API.
> >
> >I don't understand this part of Provisional API:
> >
> > "...or an externally accessible API that existed in a previous version
> > of ODL but is being modified for the current release."
> >
> >The part that is unclear to me is the state the API was in during the
> >previous version. IOW, to me it _had_ to be Provisional to begin with,
> >else you couldn't change it. If it was Legacy (Stable?) to begin with,
> >then this is a _new_ API, and certainly the new API is Provisional.
> >
> >Also, I think the APIs should be marked in code, annotations being one
> >obvious way to do it (in today's call we touched on deprecated, and only
> >exporting supported APIs)? The ability to enumerate externally consumable
> >APIs should be automated, and even better, the API state marked in the
> >code so that it's clear to the consumer what contract you are receiving.
>
> Unfortunately, we have had little consensus on the fact that we should be
> marking APIs.

I think it's a good idea, what is your opinion?

> We currently completely lack the tools to do so in the models, too.

Do you think that's an insurmountable issue or more a matter of someone
w/ the time to do this work? I'm assuming the later given your reference
to @Deprecated and @Beta w/ yangtools.

> I would hate to associate the word 'stable' with an API. In confers a sense
> of matureness simply not present in a lot of Helium APIs.

Hrm, you don't like Stable, I don't like Legacy. Only other word that
springs to mind is Supported. I do think Stable conveys the right
message, i.e. it won't change on you.

> I think clarifying/documenting the API intent in the early stages of this
> particular release is a good thing, simply because it has not really
> happened in the last release.

Yeah, I agree.

> At this point we do not have a clear proposal on how to mark the APIs, much
> less a proven mechanism. I think that disqualifies it from being mandatory
> in this release, but yes, we need something going forward. Yangtools has
> trailblazed with using @Deprecated and @Beta, but the problem is a lot more
> complicated than that, and most of our code does not even use the visibility
> modifiers properly -- any taker for writing a guideline?

To be clear, I'm not suggesting mandatory. I am suggesting that we
support being clear in the code so that we can enumerate w/out that
being manual (the template requires submitting a list of APIs which
strikes me as a waste of time if we can generate the list), and clearly
show the API status to consumers through annotations, javadoc, etc.

What I've seen in Spark fairly typical annotation def'n:

@Retention(value=RUNTIME)
@Target(value={TYPE,FIELD,METHOD,PARAMETER,CONSTRUCTOR,LOCAL_VARIABLE,PACKAGE})
public @interface Experimental

Would it be useful to have org.opendaylight.annotation?

thanks,
-chris

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

Abhijit Kumbhare

#2004

Fully agree on Ed's point:

"Further, I would strongly suggest that we adopt a calling out of Legacy(Stable APIs) rather than a
calling out of Provisional/Tentative APIs. Unless we are going to essentially force API freeze at M1,
I as a developer have *no* way of knowing what APIs will prove needful as we do development,
so defaulting to Legacy(Stable) makes no sense to me. It is important to keep in mind that a projects
Release Plan is a statement of what it thinks it will do, not a restriction on what it *can* do. To treat it otherwise
is to choke innovation."

To that point - I think we should remove the sentence about M3 from the tentative API definition:

Tentative API: A Provisional API that will be provided in a best effort manner, but which may or may not be delivered in the final release. The Go/NoGo status of Tentative APIs must be made by M3.

Show quoted text

On Wed, Oct 29, 2014 at 1:26 PM, Ed Warnicke (eaw) <eaw@...> wrote:

> On Oct 24, 2014, at 1:49 PM, Chris Wright <chrisw@...> wrote:
>
> * Colin Dixon (colin@...) wrote:
>> The draft release plan that Phil and I have been working on is ready for
>> comments. You can find it here:
>> https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckd
>
> I think a Legacy API sounds like something old where there is also a
> newer way to do the same thing. I'd suggest Stable API.

I was thinking something similar, and concur. To my ear, a legacy API is something we
expect to be deprecating sooner or later (other ears may disagree ;) ). So I second renaming
Legacy API to Stable API in the plan.

I would also suggest that we need to figure out what the exception process looks like, because there is
*always* an exception to every rule.

Further, I would strongly suggest that we adopt a calling out of Legacy(Stable APIs) rather than a
calling out of Provisional/Tentative APIs. Unless we are going to essentially force API freeze at M1,
I as a developer have *no* way of knowing what APIs will prove needful as we do development,
so defaulting to Legacy(Stable) makes no sense to me. It is important to keep in mind that a projects
Release Plan is a statement of what it thinks it will do, not a restriction on what it *can* do. To treat it otherwise
is to choke innovation.

>
> I don't understand this part of Provisional API:
>
> "...or an externally accessible API that existed in a previous version
> of ODL but is being modified for the current release."
>
> The part that is unclear to me is the state the API was in during the
> previous version. IOW, to me it _had_ to be Provisional to begin with,
> else you couldn't change it. If it was Legacy (Stable?) to begin with,
> then this is a _new_ API, and certainly the new API is Provisional.
>
> Also, I think the APIs should be marked in code, annotations being one
> obvious way to do it (in today's call we touched on deprecated, and only
> exporting supported APIs)? The ability to enumerate externally consumable
> APIs should be automated, and even better, the API state marked in the
> code so that it's clear to the consumer what contract you are receiving.

I strongly concur about marking in code… anyone willing to do a quick annotation?

Ed

>
> thanks,
> -chris
> _______________________________________________
> TSC mailing list
> TSC@...
> https://lists.opendaylight.org/mailman/listinfo/tsc

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc