Release procedure proposal for multiple artifacts

[Tim van der Lippe]

Hey all,

So some exciting news: Rafael fixed ByteBuddy to enable Mockito on Android! This is really cool, especially since Dexmaker is kinda dead.

While this is really cool, I do think we have to take a good look on how we publish this version of Mockito. Therefore my proposal on how to handle this:

I propose (which Rafael also proposed) to publish a separate artifact named `mockito-android`. Primarily because this artifact depends on net.bytebuddy:byte-buddy-android which would be unreasonable for all other users to let them download this dependency.

Quick side-step regarding the inline mockmaker: enabling this feature seems to cause quite some confusion. Therefore we could publish an artifact `mockito-inline` which enables the mockmaker by default. This would be more user-friendly.

======================================

All right, so the proposal is to publish separate artifacts, but this has implications for the release procedure. To minimize the amount of maintenance required by the core team, I propose slight changes in the procedure.

Whenever `mockito-core` is updated, the subproject artifacts have to be updated as well. However, we might have broken stuff in the Android ecosystem which we can test on Travis with a separate language (`language: android`). To make this easy for us we can create a separate project with just this Travis configuration + artifact publication logic. The same for `mockito-inline`.

Then to make this automatic, we can update the release logic in `mockito-core` to automatically open a PR to both subprojects to bump the dependency version of `mockito-core`. We as maintainers therefore only need to push the green button once the Travis build is green.

However, if we release on every single PR, we generate a lot of new PRs on the subprojects. I think we should definitely avoid this situation. For example today we merged 5 PRs (https://github.com/mockito/mockito/pulls?utf8=%E2%9C%93&q=is%3Apr%20is%3Aclosed%20merged%3A2016-11-25..2016-11-26%20) which triggered 3 separate releases. This would mean that in the normal situation we would need to merge a total of 9 PRs.

To prevent this, I think we should only publish once a day IF AND ONLY IF meaningful changes were made. E.g. feature added or bug fixed. No refactorings, doc updates, internal changes/cleanup or build changes. I do not think an automatic system can be built which is 100% accurate. Especially since today we released 3 versions which should have been 0 in my opinion.

Therefore I propose that the trigger to publish a release is done via commit. In other words: all release logic remains, but the trigger is changed to "did a core developer create a commit that publishes a release". This way we as developers can decide when to publish and publish meaningful releases.

========================================

I am looking forward to your point of view and let's incorporate Android into Mockito officially!

Regards,

Tim

[Rafael Winterhalter]

Hei Tim,

thanks for your summary. I agree with you that we should publish three artifacts, one core, one inline and one for Android. The inline artifact is mostly a convenience, I have talked to quite some folks that struggle with setting up the inline mock maker. I know it seems ridiculous but we should not forget that there are a lot of people out there that are not too familiar with the JVM and a simple typo can already break your setup. With the single artifact import, this can be fixed. Fortunately enough, adding mockito-inline would also activate the new mock maker if Mockito core was available transitively via another dependency, so this makes things really easy to use.

The Android and inline artifacts should follow the same version number and I also think they should be published every time a Mockito core update is happening. They are merely extensions. Especially in the Android space, it is common to write normal unit tests and emulator tests where tests can be run in both environments, it would be too bad if those would require seperate updates of Mockito to maintain them.

The whole PR part feels like an overkill, however. Can we not simply publish three artifacts whenever we do a release? I do this with byte-buddy-android, the least which is an extension to Byte Buddy. What about the testng artifact, by the way? Has this become obsolete?

On a side note, I asked people in an Android forum to test Mockito-Android. I already got very enthusiastic feedback! It works even on larger projects and without any of the tedious setup that is required by Mockito-Dexmaker. For the latter, you currently need to run som preparation logic in every single test class where you also need to check if you are running on Android in the first place and it also requires using Android specific APIs what makes the tests non-portable. Its a major PITA and this change will make sure that Mockito will become the single mocking framework in the Android space which is about 40% of all Java users. Even an Android Googler reached out to me and told me how great this was. This is gonna be a major thing! Lets get it out.

Cheers, Rafael

--
You received this message because you are subscribed to the Google Groups "mockito-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mockito-dev+unsubscribe@googlegroups.com.
To post to this group, send email to mocki...@googlegroups.com.
Visit this group at https://groups.google.com/group/mockito-dev.
For more options, visit https://groups.google.com/d/optout.

[Tim van der Lippe]

Glad to hear the Android folks like it!

The reason I proposed separate repos for the artifacts is so we have an easier Travis configuration. We can have a separate yml for the Android sdk installation and testing just that artifact.

At the moment I fixed it in the branch, but that is not mergeable. Tbh I do not even know if the CI is correctly testing the artifact.

To unsubscribe from this group and stop receiving emails from it, send an email to mockito-dev...@googlegroups.com.

To post to this group, send email to mocki...@googlegroups.com.
Visit this group at https://groups.google.com/group/mockito-dev.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "mockito-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mockito-dev...@googlegroups.com.