Comments (14)
Will each breaking commit (indicated by the "BREAKING CHANGE:" footer) trigger a new major pre-release in the beta branch?
I think it will make v5.0.0-beta.1
, but better make sure through experimentation as you suggested.
Otherwise, the proposed approach sounds good to me!
from karma-jasmine.
will there also be a tax on contributors and maintainers once this is set up?
I don't think contributors are affected in any way. Slight extra effort required from the maintainers to backport occasional fixes to another branch, but IMO that shouldn't be significant.
Was there some incident that inspired filing this issue, or are you just being proactive?
We use semantic-release
to automatically publish each merged PR as a new version. When merging breaking changes, it will automatically bump a major version. The primary problem we're solving here is that we don't want every breaking change to result in a new major release (which quickly gets out of control and results in noise and update friction), but instead have a way to batch several breaking changes into a single major release.
We would still use semantic-release
to automatically publish each merged PR, but from the beta
branch it would result in 6.0.0-beta.0, 6.0.0-beta-1, 6.0.0-beta.2 (and eventually 6.0.0 containing all previous changes) instead of 6.0.0, 7.0.0, 8.0.0, etc.
When you talk about "breaking changes", do you mean our CI still passes but downstream users may be broken e.g. due to API migrations/etc? It seems you're referring to intentionally breaking changes, which contrasts with unintentionally breaking changes which should be caught by CI.
Yes, it's intential breaking changes. E.g. drop support for the obsolete Node version, remove deprecated or obsolete APIs, etc. As I understand these should not be breaking changes for Google as all usages should be cleaned up prior to landing the change, but for external user it goes other way around and we should communicate such changes with major version bump.
from karma-jasmine.
I'd be happy to test beta releases out in our StrykerJS e2e test suite. Especially if it saves us having to fix breaking issues for users later on 😅
Q: How will these beta releases be communicated?
from karma-jasmine.
RFC
@XhmikosR
@mtrea
@devoto13
@nicojs
@sgravrock
from karma-jasmine.
How do you envision it to work?
My thinking is that with the limited maintainer time and given the small amount of breaking changes continuously maintaining multiple branches and backporting all changes is not worth the effort. So I would suggest the below workflow.
master
branch contains the latest version of the library as it is today. Most of the time it is the latest stable version of the library, so PRs sent to it should be non-breaking and will be immediately released as stable. Periodically, we would switch the master
branch into a prerelease mode (by changing the Semantic Release config). In this mode, we can merge both breaking and non-breaking PRs and they will be released immediately as next
/pre-release versions on NPM so that users can install and test them. Once we've merged all breaking changes, we switch the master
branch back into stable mode and Semantic Release will cut a single major release with all breaking changes.
Whenever we switch the master
branch into the pre-release mode, we'll also create release/N.x
(where N is the current major number) and protect it. We can send PRs against this branch to backport critical fixes to the stable version or contributors can open PRs against it in the future. The branch is also automatically released by the Semantic Release.
from karma-jasmine.
I was thinking about following the pre-releases
recipe from semantic release.
- The
master
branch would always track the@latest
"stable release". - We create a protected
beta
branch to track@beta
"prereleases". - All breaking PRs should be filed against
beta
and each merge triggers a new beta prerelease (e.g. v5.0.0-beta.0). - When deemed necessary we promote beta to stable:
- We merge
beta
tomaster
, releasing a new major stable version. - The old major stable version goes out of support.
- When necessary
beta
can diverge frommaster
again.
- We merge
from karma-jasmine.
Sibling bug: karma-runner/karma#3774
from karma-jasmine.
One question that is unclear to me still:
Will each breaking commit (indicated by the "BREAKING CHANGE:" footer) trigger a new major pre-release in the beta
branch?
For example, let's say that the latest stable version currently is v4.0.2. We diverge from it via the beta
branch with a PR that contains a breaking commit. This should immediately release version v5.0.0-beta.0. Let's say there is another PR with a breaking commit merged onto the beta
branch. Will that trigger the release of version v5.0.0-beta.1 or v6.0.0-beta.0? It is not immediately clear from the pre-releases recipe. I would need to find out via experimentation. I think the right behavior should be that it triggers the release of v5.0.0-beta.1 as beta is considered unstable and it is permissible to introduce new breaking changes upon every PR merge.
WDYT @devoto13 ?
from karma-jasmine.
This should be the same across all the other repos that need a beta release. Do you agree @devoto13 ?
from karma-jasmine.
@karma-runner/google-web-test-team
from karma-jasmine.
It sounds like @jginsburgn's clarifications addressed @devoto13's concerns re:limited maintainer time, continuously maintaining multiple branches and backporting all changes.
I would like to nail down the positive/negative impacts of this change a bit more. Positive is that we mitigate breaking changes reaching stable. Negative is some increased complexity in the project; will there also be a tax on contributors and maintainers once this is set up? Was there some incident that inspired filing this issue, or are you just being proactive?
When you talk about "breaking changes", do you mean our CI still passes but downstream users may be broken e.g. due to API migrations/etc? It seems you're referring to intentionally breaking changes, which contrasts with unintentionally breaking changes which should be caught by CI.
from karma-jasmine.
Plus one to what @devoto13 responded. Nothing to add.
Do you have any other concerns here @mtrea ?
from karma-jasmine.
Nope, go for it!
from karma-jasmine.
I'd be happy to test beta releases out in our StrykerJS e2e test suite. Especially if it saves us having to fix breaking issues for users later on 😅
Q: How will these beta releases be communicated?
@nicojs that is a great idea! I think it would make our release process safer.
I haven't thought about how to decide when to merge the beta
branch discussed above. A suggestion would be to stick to the Node.js lifecycle. WDYT?
In parallel, however, I think we could add the Stryker e2e test suite as an extension of our integration tests repo and run it as a step in every PR.
Tell me your thoughts.
from karma-jasmine.
Related Issues (20)
- spec selection does not work anymore HOT 1
- DOMTestComponentRenderer.insertRootElement when mocking document.querySelectorAll HOT 1
- jasmine's failFast not working in 4.0.1
- Sends report before tests finish running HOT 1
- Unused packages detected in the karmajasmine project on Tag: v4.0.1 HOT 1
- Add CI/CD with GitHub Actions HOT 1
- specFilter causes timeout with large amount of tests HOT 1
- Jasmine 4 support? HOT 1
- Reestablish CI/CD with GitHub Actions HOT 1
- Duplicate error messages (reopen)
- Linting Should Run in Its Own Workflow
- Convert tools/integration-tests.sh to a cross-platform script HOT 3
- Update eslint-config-standard HOT 4
- Uncaught (in promise) Type Error: Cannot read properties of null (reading 'jasmineMessage') HOT 3
- Opening Context.html window raises an error for parentWindow.karma object "Cannot read property 'info' of undefined" HOT 1
- Support for Jasmine 5 HOT 2
- Add doc deprecation for karma-jasmine with recommendations
- Karma failing with CI/CD
- Incorrect link in 5.0.0 release notes
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from karma-jasmine.