Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Mockito Continuous Delivery Pipeline 2.0 #911
Proposed changes on easy-to-grasp diagrams are documented on Mockito blog article.
Current release model
Every code change results in a new version in Central repository (not snapshot, a real version). More information on Continuous Delivery in Mockito.
Given high rate of new versions, the community and current tooling is not comfortable in taking in new Mockito versions at fast pace. More feedback and the discussion in issue #618.
Release every change but not all releases go to Central. Push to standard repository (JCenter / Maven Central) only substantial releases. Push remaining versions to less prominent, but still public space for early adopters.
Glossary: What are major, minor, patch versions? Explanatory example: Version 2.6.5 has major=2, minor=6, patch=5.
For more details, see the wiki page paragraph on continuous delivery.
I do agree for major, but for minor I am not sure. I think we should not immediately release a new minor version when 1 function was added, most notably because we might want to add a range of functions in all separate PRs (since they are separate logical units). Therefore I would say to not do it automatically, but presumably faster than with patch releases. E.g. minor every week published, patch every month.
This means that 2.81 and 2.8.2 are never available on production? I do think we should push this for 1. consistency in release versions and 2. if someone finds an issue with a version in
I would like to add an override here for to be able to push a new version. E.g. not pushing an existing version to production, but publishing a new version without manually editing javadoc to artificially trigger the release mechanism
Overall I agree with the proposal, just some small comments. Glad that we are taking action in this direction
Great feedback thank you!
"minor" version (e.g. middle number :) is not automatically bumped by the system. It's us (or the PR submitter) that makes a judgement call to explicitly bump minor version. This decision is based on the gravity of the changes. We don't bump minor version unless it has substantial changes. If it does have substantial changes, it probably should be released to mass audience. At least this is my reasoning. If we don't automatically publish minor versions we can end up with versioning scheme where "community" and "prod" repo have pretty much random versions. If we publish minor versions automatically, "prod" contains announcable, significant versions that add substantial value, e.g. 3.1.0, 3.2.0, 3.3.0 and occasional patch release like 3.3.1. "community" repo would have all changes 3.1.0, 3.1.1, 3.1.2, 3.1.3, 3.2.0, etc. Thoughts?
The idea is to only include substantial versions in official repo. If the user wants to bisect, he needs configure "community" repo explicitly in pom / build.gradle. In short, the answer to your question is yes, 2.8.1 and 2.8.2 will never be in "production" repo.
Let's keep thinking. Some other ideas: all-versions/announcable-versions, all-artifacts/significant-artifacts, early-adopters/slow-adopters.
Given that "minor" version (e.g. middle one) is updated explicitly by the PR submitter, he controls
Good idea. I will add it to the design.
Really nice feedback. Thanks! We can tweak/iterate the process as we learn more, too.
I think for clarity's sake, they should be pushed. It would be weird to browse maven central and see missing versions. Let's see what the others think.
Latest - Stable?
I can think of two popular projects which sometines skip versions:
This looks good! I agree with the model where minor versions are in release channel (notable-versions) and patch versions are in beta channel (all-versions), modulo hot fixes. If patch versions are pushed to notable-versions at the time they are released, you defeat the purpose of the release channel; your "notable versions" channel would churn multiple times daily again.
Maybe Mockito can push all interleaved patch versions available only on the beta channel to the release channel when the release channel is updated? For example:
This may go against the principle of least surprise, since someone browsing the version history of release channel will notice that suddenly not one but three new versions became visible. This may be acceptable if bisecting and keeping full version history on the release channel are important for the project. As I said before, I don't have a strong preference for this model, except to say that patch versions should not appear in the release channel at the time of their release unless they are hot fixes.
I have an alternative opinion from everything proposed so far. I propose introducing the usage of the
<!-- Current usage, unchanged! --> <dependency> <groupId>org.mockito</groupId> <artifactId>mockito-core</artifactId> <version>2.7.5</version> </dependency> <!-- Using the `weekly` classifier --> <dependency> <groupId>org.mockito</groupId> <artifactId>mockito-core</artifactId> <classifier>weekly</classifier> <version>2.7.1</version> </dependency>
This could also be inverted to restore the delayed release process to the majority of consumers and allow opting in to the daily/continuous releases.
<dependency> <groupId>org.mockito</groupId> <artifactId>mockito-core</artifactId> <classifier>daily</classifier> <version>2.7.5</version> </dependency> <dependency> <groupId>org.mockito</groupId> <artifactId>mockito-core</artifactId> <version>2.7.1</version> </dependency>
With Gradle version ordering (https://docs.gradle .org/current/userguide/single_versions.html#version_ordering), if any publisher wants to use dynamic version such as 3.7.+ to follow minor versions, then we should not publish any snapshot releases (see this feature request: gradle/gradle#8126). Mockito team found a workaround for this: having two artifacts ID for the same product: one for development with snapshot releases, one for customer with no snapshot releases (see mockito/mockito#911). During the development, we could have all our product (SDK and adapters) using the dev releases with dynamic versions. Any snapshot releases is possible without breaking any changes for any publishers. Once we want to make a release, only true (customer) releases are used, without any dynamic versions. Change-Id: Id7226175546f175557078645ecc09c9049f43ed4 JIRA: EE-1138