Topics

Toward the next release and (proposed) release system changes


Bob Jacobsen
 

There’s now a GitHub issue around migrating to the (proposed) new release system:

https://github.com/JMRI/JMRI/issues/8831

We should decide soon whether to do it or not.

As a reminder: This started almost a month ago (June 18) with the question of whether we (well, I) could use a less draconian deprecation policy between now and December. As often happens, that rapidly grew into lots of other Great Things that can be done.

So the question is now whether we can cap off one of those discussions, and move along. Specifically, the change to three release streams with defined contents. (See https://github.com/JMRI/JMRI/issues/8831 for the concrete steps)

I leave to others and the future the question of _when_ to release the minor and major change branches. That can wait for a bit, three weeks at most.

I also leave to the future whether or not to define and/or denote specific API properties in the code. If somebody wants to do that, fine, but it’s not one of my priorities. Ditto prepping for a change to required/supported Java version.

So, in an effort to be concrete:

-> Unless there’s a clear consensus _not_ to do this before then, the `master` branch will be locked mid-morning Friday July 17, JMRI 4.21.1 will be released from it, and (hopefully) the new process will be in place by late Sunday July 19.

-> Once the process starts, should it start, the changes will be done as described in https://github.com/JMRI/JMRI/issues/8831 and https://github.com/JMRI/JMRI/pull/8832 If you would instead prefer something else, propose a specific change for discussion here.

Bob


Bob Jacobsen
@BobJacobsen


danielb987
 

I'm fine with this.

- We'll define four new labels for GitHub PRs:
- Breaking Change
- Feature
- Fix
- Chore
- A PR must have exactly one of those applied for it to be merged
- The author of the PR can propose a label, in which case only one reviewer is required.
- If the author of the PR does not propose a label, two reviewers must sign off on the right label.
I suggest that the "mergeable" bot prints a reminder of this in the PR, unless the PR already has one of these labels. The following paragraph may be good to include in that reminder as a help to choose the correct label:

There's some judgement involved in this labelling process. An algorithmic change might change behavior enough to add a new feature (`Feature`) or cause issues for downstream code (`Breaking Change`). On the other hand, changing a class API by marking methods as deprecated for future removal is not a breaking change _yet_, and can be marked as `Fix`.


Set Github protections so master cannot accidentally be updated by PRs
Create the new branches: (we are temporarily leaving master as-is just this first time)
Can we developers stay on master and make PRs to master, or should we make PRs against some other branch? I'm asking to make sure I understand the process.

Daniel


Dan Boudreau
 

I’m fine with the proposal as long as I can continue to make PR to the same branch.  In the past this was called “master”, don’t care what the new branch is called as long as its consistent.

 

Dan

 

From: Bob Jacobsen
Sent: Monday, July 13, 2020 5:15 PM
To: jmri@jmri-developers.groups.io Notification
Subject: [jmri-developers] Toward the next release and (proposed) release system changes

 

There’s now a GitHub issue around migrating to the (proposed) new release system:

https://github.com/JMRI/JMRI/issues/8831

We should decide soon whether to do it or not.

As a reminder: This started almost a month ago (June 18) with the question of whether we (well, I) could use a less draconian deprecation policy between now and December.  As often happens, that rapidly grew into lots of other Great Things that can be done.

So the question is now whether we can cap off one of those discussions, and move along.  Specifically, the change to three release streams with defined contents. (See https://github.com/JMRI/JMRI/issues/8831 for the concrete steps)

I leave to others and the future the question of _when_ to release the minor and major change branches.  That can wait for a bit, three weeks at most.

I also leave to the future whether or not to define and/or denote specific API properties in the code. If somebody wants to do that, fine, but it’s not one of my priorities. Ditto prepping for a change to required/supported Java version.

So, in an effort to be concrete:

-> Unless there’s a clear consensus _not_ to do this before then, the `master` branch will be locked mid-morning Friday July 17, JMRI 4.21.1 will be released from it, and (hopefully) the new process will be in place by late Sunday July 19.

-> Once the process starts, should it start, the changes will be done as described in https://github.com/JMRI/JMRI/issues/8831 and https://github.com/JMRI/JMRI/pull/8832 If you would instead prefer something else, propose a specific change for discussion here.

Bob


Bob Jacobsen
rgj1927@...





 


Steve_G
 

Well, I have been following this, the further it goes on the less I understand what problem we a trying to solve and how this makes life easier. I suspect most users would be happy with a date as the version (like eclipse) or a plan number. This is starting to look like an intellectual exercise, not that this surprises me as it sometimes has the feeling of being a test bed for development toys. 
Having said that, if you just tell me which branch I make changes against, and don't keep changing it, use any numbering system you like.
Steve G.