Topics

Do we have a decision about skip deprecation for next major version?


danielb987
 

It seems to me that we are going to either do a deprecation holiday as suggested by Bob Jacobsen or follow Randal Woods suggestion about strictly using semantic versioning. In either case, we would not need to deprecate for the next major version.

I would like to get #8707, Split Light into Light and Variablelight, merged into master, and if deprecation is not needed I can simplify this PR by removing the interface CommonLight.

So my question is: Can I assume that the next major version of JMRI do not need things deprecated?

Daniel


Bob Jacobsen
 

I don’t know whether we have a decision yet.

I didn’t see any support for a deprecation holiday other than my original suggestion, so I doubt there’s agreement to do that.

I’m OK with the semantic versioning idea, have put some effort into it, but there doesn’t seem to be widespread support for that either. If we’re going to do that, we need to have a discussion and converge on answer to (1) how/when we decide to publish each of the three kinds of releases and (2) how/when we decide to recommend one of them to the user community. Providing improving versions JMRI applications to model railroaders is our primary output, so we should figure out how to do it in a new environment. (It seems clear that the versioning proposal is better for developers and API users)

I think the timeline for decision is the next 4-5 days. I hope to get 4.19.9 out today, and make 4.20 Sunday for announcement early next week. If that holds, and if we decide on semantic versioning, we can (do the steps to) set that up this weekend.

Bob

On Jul 1, 2020, at 7:14 AM, danielb987 <db123@...> wrote:

It seems to me that we are going to either do a deprecation holiday as suggested by Bob Jacobsen or follow Randal Woods suggestion about strictly using semantic versioning. In either case, we would not need to deprecate for the next major version.

I would like to get #8707, Split Light into Light and Variablelight, merged into master, and if deprecation is not needed I can simplify this PR by removing the interface CommonLight.

So my question is: Can I assume that the next major version of JMRI do not need things deprecated?

Daniel



Bob Jacobsen
@BobJacobsen


danielb987
 

I support both alternatives. The only reason I haven't given any answer is that I'm relative new to JMRI and don't have much experience or knowledge in these questions. I focus on the development of the code itself and leave the questions about versioning and releases to others.

One thought about semantic versioning idea and the MAJOR version number:
It's probably a lot of work, but if we get the jmri.** package to be a Java Module and the apps.** package to be another Java Module, then we will get a new MAJOR version when the jmri.** Java Module changes its interface in a non compatible way. My point with this definition is that it would allow public classes and methods in jmri.** that's not published in the jmri.** Java Module to be changed/removed without having a new MAJOR version.

But that results in a new difficult question: What should be published in the jmri.** Java Module? A question that's off topic of this thread.

Daniel

2020-07-01 17:52 skrev Bob Jacobsen:

I don’t know whether we have a decision yet.
I didn’t see any support for a deprecation holiday other than my
original suggestion, so I doubt there’s agreement to do that.
I’m OK with the semantic versioning idea, have put some effort into
it, but there doesn’t seem to be widespread support for that either.
If we’re going to do that, we need to have a discussion and converge
on answer to (1) how/when we decide to publish each of the three kinds
of releases and (2) how/when we decide to recommend one of them to the
user community. Providing improving versions JMRI applications to
model railroaders is our primary output, so we should figure out how
to do it in a new environment. (It seems clear that the versioning
proposal is better for developers and API users)
I think the timeline for decision is the next 4-5 days. I hope to get
4.19.9 out today, and make 4.20 Sunday for announcement early next
week. If that holds, and if we decide on semantic versioning, we can
(do the steps to) set that up this weekend.
Bob

On Jul 1, 2020, at 7:14 AM, danielb987 <db123@...> wrote:
It seems to me that we are going to either do a deprecation holiday as suggested by Bob Jacobsen or follow Randal Woods suggestion about strictly using semantic versioning. In either case, we would not need to deprecate for the next major version.
I would like to get #8707, Split Light into Light and Variablelight, merged into master, and if deprecation is not needed I can simplify this PR by removing the interface CommonLight.
So my question is: Can I assume that the next major version of JMRI do not need things deprecated?
Daniel

Bob Jacobsen
@BobJacobsen


Andrew Crosland
 

I'm keeping quiet as I still don't fully understand all the nuances of the way JMRI is put together. Added to that I'm a hardware engineer by training and experience.

I trust Bob, Randall and the wider group to make the right decision :)

Andrew

------ Original Message ------
From: "danielb987" <db123@...>
To: jmri@jmri-developers.groups.io
Sent: 01/07/2020 17:26:37
Subject: Re: [jmri-developers] Do we have a decision about skip deprecation for next major version?

I support both alternatives. The only reason I haven't given any answer is that I'm relative new to JMRI and don't have much experience or knowledge in these questions. I focus on the development of the code itself and leave the questions about versioning and releases to others.

One thought about semantic versioning idea and the MAJOR version number:
It's probably a lot of work, but if we get the jmri.** package to be a Java Module and the apps.** package to be another Java Module, then we will get a new MAJOR version when the jmri.** Java Module changes its interface in a non compatible way. My point with this definition is that it would allow public classes and methods in jmri.** that's not published in the jmri.** Java Module to be changed/removed without having a new MAJOR version.

But that results in a new difficult question: What should be published in the jmri.** Java Module? A question that's off topic of this thread.

Daniel

2020-07-01 17:52 skrev Bob Jacobsen:
I don’t know whether we have a decision yet.

I didn’t see any support for a deprecation holiday other than my
original suggestion, so I doubt there’s agreement to do that.

I’m OK with the semantic versioning idea, have put some effort into
it, but there doesn’t seem to be widespread support for that either.
If we’re going to do that, we need to have a discussion and converge
on answer to (1) how/when we decide to publish each of the three kinds
of releases and (2) how/when we decide to recommend one of them to the
user community. Providing improving versions JMRI applications to
model railroaders is our primary output, so we should figure out how
to do it in a new environment. (It seems clear that the versioning
proposal is better for developers and API users)

I think the timeline for decision is the next 4-5 days. I hope to get
4.19.9 out today, and make 4.20 Sunday for announcement early next
week. If that holds, and if we decide on semantic versioning, we can
(do the steps to) set that up this weekend.

Bob

On Jul 1, 2020, at 7:14 AM, danielb987 <db123@...> wrote:

It seems to me that we are going to either do a deprecation holiday as suggested by Bob Jacobsen or follow Randal Woods suggestion about strictly using semantic versioning. In either case, we would not need to deprecate for the next major version.

I would like to get #8707, Split Light into Light and Variablelight, merged into master, and if deprecation is not needed I can simplify this PR by removing the interface CommonLight.

So my question is: Can I assume that the next major version of JMRI do not need things deprecated?

Daniel



Bob Jacobsen
@BobJacobsen








--
Andrew Crosland


Randall Wood <rhwood@...>
 

I suggest we use the annotations from [API Guardian](https://github.com/apiguardian-team/apiguardian) to indicate what’s usable by design by implementers and scripters and declare everything else to be “implementation details” subject to change at will. By using these annotations we can allow what must be public to compile, but add a declarative layer over that to indicate that some public classes/methods/fields should not be relied upon.

See https://junit.org/junit5/docs/current/user-guide/#api-evolution for an example of tables automatically generated using those annotations. See also the [JUnit 5 Javadocs](https://junit.org/junit5/docs/current/api/) for how the annotations appear in Javadocs.

On 01-Jul-2020, at 12:40, Andrew Crosland <andrew@...> wrote:

I'm keeping quiet as I still don't fully understand all the nuances of the way JMRI is put together. Added to that I'm a hardware engineer by training and experience.

I trust Bob, Randall and the wider group to make the right decision :)

Andrew

------ Original Message ------
From: "danielb987" <db123@...>
To: jmri@jmri-developers.groups.io
Sent: 01/07/2020 17:26:37
Subject: Re: [jmri-developers] Do we have a decision about skip deprecation for next major version?

I support both alternatives. The only reason I haven't given any answer is that I'm relative new to JMRI and don't have much experience or knowledge in these questions. I focus on the development of the code itself and leave the questions about versioning and releases to others.

One thought about semantic versioning idea and the MAJOR version number:
It's probably a lot of work, but if we get the jmri.** package to be a Java Module and the apps.** package to be another Java Module, then we will get a new MAJOR version when the jmri.** Java Module changes its interface in a non compatible way. My point with this definition is that it would allow public classes and methods in jmri.** that's not published in the jmri.** Java Module to be changed/removed without having a new MAJOR version.

But that results in a new difficult question: What should be published in the jmri.** Java Module? A question that's off topic of this thread.

Daniel

2020-07-01 17:52 skrev Bob Jacobsen:
I don’t know whether we have a decision yet.

I didn’t see any support for a deprecation holiday other than my
original suggestion, so I doubt there’s agreement to do that.

I’m OK with the semantic versioning idea, have put some effort into
it, but there doesn’t seem to be widespread support for that either.
If we’re going to do that, we need to have a discussion and converge
on answer to (1) how/when we decide to publish each of the three kinds
of releases and (2) how/when we decide to recommend one of them to the
user community.  Providing improving versions JMRI applications to
model railroaders is our primary output, so we should figure out how
to do it in a new environment.  (It seems clear that the versioning
proposal is better for developers and API users)

I think the timeline for decision is the next 4-5 days.  I hope to get
4.19.9 out today, and make 4.20 Sunday for announcement early next
week.  If that holds, and if we decide on semantic versioning, we can
(do the steps to) set that up this weekend.

Bob

On Jul 1, 2020, at 7:14 AM, danielb987 <db123@...> wrote:

It seems to me that we are going to either do a deprecation holiday as suggested by Bob Jacobsen or follow Randal Woods suggestion about strictly using semantic versioning. In either case, we would not need to deprecate for the next major version.

I would like to get #8707, Split Light into Light and Variablelight, merged into master, and if deprecation is not needed I can simplify this PR by removing the interface CommonLight.

So my question is: Can I assume that the next major version of JMRI do not need things deprecated?

Daniel





Bob Jacobsen
rgj1927@...












-- 
Andrew Crosland



danielb987
 

Sounds good to me.

Daniel

2020-07-02 12:40 skrev Randall Wood via groups.io:

I suggest we use the annotations from [API
Guardian](https://github.com/apiguardian-team/apiguardian) to indicate
what’s usable by design by implementers and scripters and declare
everything else to be “implementation details” subject to change
at will. By using these annotations we can allow what must be public
to compile, but add a declarative layer over that to indicate that
some public classes/methods/fields should not be relied upon.
See https://junit.org/junit5/docs/current/user-guide/#api-evolution
for an example of tables automatically generated using those
annotations. See also the [JUnit 5
Javadocs](https://junit.org/junit5/docs/current/api/) for how the
annotations appear in Javadocs.