Feat: 1639 release process for minor versions #1657

jcpitre · 2024-01-24T05:44:45Z

Summary:

Added some documentation about the branching and release strategy.

github-actions · 2024-01-24T07:31:42Z

✅ Rule acceptance tests passed.
New Errors: 0 out of 1480 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%.
Dropped Errors: 0 out of 1480 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%.
New Warnings: 0 out of 1480 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%.
Dropped Warnings: 0 out of 1480 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%.
1 out of 1481 sources (~0 %) are corrupted.
Corrupted sources:
pl-pomorskie-zarzad-transportu-miejskiego-gdansk-ztm-gdansk-gtfs-1014
Commit: a883fe2
Download the full acceptance test report here (report will disappear after 90 days).
✅ Rule acceptance tests passed.

jcpitre · 2024-02-01T14:20:31Z

@emmambd You can review now.

emmambd · 2024-02-01T15:08:12Z

docs/BRANCHING.md

+## General Considerations
+
+- Generally the master branch is the one where current development is happening.
+- One objective would be to arrive to a point where the master branch can be released very often (every day?).


@jcpitre It should be measurable what the goal is here (and we should commit to it in the text). How's once every two weeks, given that we're not always working on the validator? Or do we want to be decisive about daily? @davidgamez

Removed the section about releasing often or daily

github-actions · 2024-02-01T15:08:23Z

✅ Rule acceptance tests passed.
New Errors: 0 out of 1480 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%.
Dropped Errors: 0 out of 1480 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%.
New Warnings: 0 out of 1480 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%.
Dropped Warnings: 0 out of 1480 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%.
0 out of 1480 sources (~0 %) are corrupted.
Commit: 3b85b96
Download the full acceptance test report here (report will disappear after 90 days).
✅ Rule acceptance tests passed.

emmambd · 2024-02-01T15:09:04Z

docs/BRANCHING.md

+
+## Release numbering
+- example 4.3.0
+- The first number (4 in this example) is incremented for major changes in the software. What major change mean has to be decided.


Major = impacts the rules, either errors or warnings OR includes breaking changes for users.

So do you mean adding a rule for example will require a major number change?

Correct - any additions or modifications to validation rules.

How often are the rules changed?

I would expect at the once every 3 month cadence we talked about (we're talking about modifying equal_shape_dist_traveled_diff_coordinates and trip_distance_exceeds_shape_distance this quarter, for instance, and David's expired_calendar PR would be a rule modification). We also need to add new fares rules.

So that means we would never really have minor releases, if there are changes of rules that often. Can we qualify the changes in the rules to make some more important (and impactful) than others?

@jcpitre I think the reaction would just be to release more :) For example, we could do a minor release for everything we've merged this past month. (Not suggesting it, but going forward after this quarter)

emmambd · 2024-02-01T15:09:30Z

docs/BRANCHING.md

+## Release numbering
+- example 4.3.0
+- The first number (4 in this example) is incremented for major changes in the software. What major change mean has to be decided.
+- The second number (3 in this example) is incremented for minor changes in the software.


Minor = non-breaking changes for users, and don't impact validation rules.

emmambd · 2024-02-01T15:10:16Z

docs/BRANCHING.md

+- The first number (4 in this example) is incremented for major changes in the software. What major change mean has to be decided.
+- The second number (3 in this example) is incremented for minor changes in the software.
+- The third number (0 in this example) is used for maintenance releases.
+  A maintenance is created if some bug has to be corrected before the next minor release.


@jcpitre Can we link to an example? Such as this one: #1653

We could, except we decided not to do a maintenance release with the PR you mentioned since there was a workaround that did not involve a release. So the example might not be as convincing as we want.

What would be an example you'd use here?

Frankly I can't find any. The best is the one you mentioned. So I can put it in the document and add a comment in #1663 saying that this should lead to a maintenance release but we were lucky to have a workaround.

Added the link

docs/BRANCHING.md

emmambd · 2024-02-01T15:25:50Z

docs/BRANCHING.md

+- For example the change could be too extensive, or introduce an undue risk in the maintenance release.
+  This is true in particular if the testing infrastructure is not sufficient.
+
+## Hotfixes


It might be useful to explicitly state that we should label an issue as a "hotfix" issue, as discussed, so it's clear when a bug warrants this type of branching flow.

Added something to that effect.

emmambd · 2024-02-01T15:28:40Z

docs/BRANCHING.md

+            - For example if commit C from the diagram contains minor changes like typos we could decide that it's OK to include it in the maintenance release.
+            - In that case the hotfix branch can stem from commit C and be merged back into master in commit F.
+            - Commit F is tagged as the maintenance release and the maintenance release is built from there.
+    - If a merge on the master branch cannot be included in the maintenance release (See for example commit I) then we have no choice but to create a maintenance branch


@jcpitre So basically, if there's been a commit to master that would need to result in a major release version, then we have to create a maintenance branch?

If there is something we absolutely need to fix in the released software, yes.
Considering that normally you would not want the major commit to make it's way in the maintenance release.
But this can be true for minor commits too. Except it's not as clear cut.

github-actions · 2024-02-01T18:29:53Z

✅ Rule acceptance tests passed.
New Errors: 0 out of 1480 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%.
Dropped Errors: 0 out of 1480 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%.
New Warnings: 0 out of 1480 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%.
Dropped Warnings: 0 out of 1480 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%.
1 out of 1481 sources (~0 %) are corrupted.
Corrupted sources:
ci-abidjan-divers-operateurs-gtfs-913
Commit: 809cbc7
Download the full acceptance test report here (report will disappear after 90 days).
✅ Rule acceptance tests passed.

davidgamez · 2024-02-01T18:35:45Z

docs/BRANCHING.md

+
+- Feature/fix branch are created for every feature we want to add to the software (or bug we want to fix).
+- They stem from master, are usually short-lived and are merged back to master.
+- We already use these for adding features or fixing bugs in the master branch. 


[suggestion]: delete this line, as the concept of when we are already using them becomes unclear after this PR is merged.

github-actions · 2024-02-02T22:16:59Z

✅ Rule acceptance tests passed.
New Errors: 0 out of 1481 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%.
Dropped Errors: 0 out of 1481 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%.
New Warnings: 0 out of 1481 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%.
Dropped Warnings: 0 out of 1481 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%.
0 out of 1481 sources (~0 %) are corrupted.
Commit: 44e61b2
Download the full acceptance test report here (report will disappear after 90 days).
✅ Rule acceptance tests passed.

davidgamez

This LGTM. After this is approved, let's create an issue to align the release pipeline with the branching strategy.

github-actions · 2024-05-14T14:47:16Z

✅ Rule acceptance tests passed.
New Errors: 0 out of 1520 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%.
Dropped Errors: 0 out of 1520 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%.
New Warnings: 0 out of 1520 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%.
Dropped Warnings: 0 out of 1520 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%.
0 out of 1520 sources (~0 %) are corrupted.
Commit: dae5e13
Download the full acceptance test report here (report will disappear after 90 days).
✅ Rule acceptance tests passed.

jcpitre added 4 commits January 24, 2024 00:35

Added branching document.

545fcae

Changed doc file to uppercase.

2073d10

Corrected the diagram

e97c137

Corrected typos

a4f52ae

emmambd self-requested a review January 24, 2024 14:03

emmambd linked an issue Jan 24, 2024 that may be closed by this pull request

Release process for minor versions #1639

Closed

Minor corrections.

0eaa719

emmambd reviewed Feb 1, 2024

View reviewed changes

docs/BRANCHING.md Show resolved Hide resolved

emmambd reviewed Feb 1, 2024

View reviewed changes

emmambd requested a review from davidgamez February 1, 2024 15:26

emmambd reviewed Feb 1, 2024

View reviewed changes

jcpitre added 2 commits February 1, 2024 12:00

Modified according to PR comments

e8f0112

Modified according to PR comments 2

b7158ef

davidgamez reviewed Feb 1, 2024

View reviewed changes

Merge branch 'master' into 1639-release-process-for-minor-versions

d93648e

davidgamez approved these changes Mar 21, 2024

View reviewed changes

jcpitre and others added 2 commits May 14, 2024 09:41

Merge branch 'master' into 1639-release-process-for-minor-versions

6ef5cfb

Modified according to PR comments.

0ed86ef

jcpitre merged commit 07ec502 into master May 14, 2024
333 checks passed

jcpitre deleted the 1639-release-process-for-minor-versions branch May 14, 2024 14:59

jcpitre mentioned this pull request May 14, 2024

Align the release pipeline with the branching strategy #1759

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feat: 1639 release process for minor versions #1657

Feat: 1639 release process for minor versions #1657

jcpitre commented Jan 24, 2024

github-actions bot commented Jan 24, 2024

jcpitre commented Feb 1, 2024

emmambd Feb 1, 2024 •

edited

Loading

jcpitre Feb 1, 2024

github-actions bot commented Feb 1, 2024

emmambd Feb 1, 2024 •

edited

Loading

jcpitre Feb 1, 2024

emmambd Feb 1, 2024

jcpitre Feb 1, 2024

emmambd Feb 1, 2024

jcpitre Feb 1, 2024

emmambd Feb 1, 2024

emmambd Feb 1, 2024

emmambd Feb 1, 2024

jcpitre Feb 1, 2024 •

edited

Loading

emmambd Feb 1, 2024

jcpitre Feb 1, 2024 •

edited

Loading

jcpitre Feb 1, 2024

emmambd Feb 1, 2024

jcpitre Feb 1, 2024

emmambd Feb 1, 2024

jcpitre Feb 1, 2024

github-actions bot commented Feb 1, 2024

davidgamez Feb 1, 2024

github-actions bot commented Feb 2, 2024

davidgamez left a comment

github-actions bot commented May 14, 2024

Feat: 1639 release process for minor versions #1657

Feat: 1639 release process for minor versions #1657

Conversation

jcpitre commented Jan 24, 2024

github-actions bot commented Jan 24, 2024

jcpitre commented Feb 1, 2024

emmambd Feb 1, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

github-actions bot commented Feb 1, 2024

emmambd Feb 1, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jcpitre Feb 1, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jcpitre Feb 1, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

github-actions bot commented Feb 1, 2024

Choose a reason for hiding this comment

github-actions bot commented Feb 2, 2024

davidgamez left a comment

Choose a reason for hiding this comment

github-actions bot commented May 14, 2024

emmambd Feb 1, 2024 •

edited

Loading

emmambd Feb 1, 2024 •

edited

Loading

jcpitre Feb 1, 2024 •

edited

Loading

jcpitre Feb 1, 2024 •

edited

Loading