Timeline Mockito 2.0 and 3.0

[tvanderlippe]

Allright so this question has been lingering for quite some time now so let's make it concrete:

When do we want to finish and publish Mockito 2.0 and start working on 3.0?

https://github.com/mockito/mockito/issues/123 lists some more minor unfinished features, but I personally think they can wait. Maybe they can be published in Mockito 2.1 or so.

What are the blocking points right now for Mockito 2.0? This is probably a question for Brice or szczepiq.

Are we able to publish Mockito 2.0 on july 31th? This way we have a set deadline and everyone can finish their work without extending it again and again.

Looking forward to your thoughts.

[Rafael Winterhalter]

I agree that we should rather cut down on the amount of work done than to delay this much further. 31th of July sounds good to me, I work better when under preasure.

I think that this one should really be resolved before release: https://github.com/mockito/mockito/issues/194

In terms of refactoring, a lot of good work was done already and the code is now much cleaner, also many of the tests were improved. We do now also support Java 8 much better (default methods, better default values for java 8 return types such as Optional (now always empty when not set differently) and Stream (empty stream).

A lot of good stuff already went in, additional features can always be added easily thanks to the continous delivery.

Thumbs up on this from my side!

--
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.
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.

[Brice Dutheil]

I agree we should release by July 31th. Also I think that #194 should be addressed first.

For such big release I think a release candidate may communicate better on the intention of a near release and may involve more projects or framework/library developers to switch to mockito 2.0rc.

Thank you all for all the great work there !
— Brice

[Tim van der Lippe]

Glad to hear. Let's fix #194 and publish the release candidate on June 30th? Then we have a month spare to compensate for any possible issues and we can map out all the features we want to support in Mockito 3.0. Consequently while publishing the release candidate we can immediately ask feedback of the users to what they would like to have.

Op di 14 jun. 2016 om 14:17 schreef Brice Dutheil <brice....@gmail.com>:

[Brice Dutheil]

Sounds good to me.

-- Brice

[David Wallace]

I should probably have contributed my opinion to this months ago, but I've been kind of busy.  I am a freelance software developer working in the capital city of my country, where there is lots of IT work, and lots of organisations using Mockito "for real" - that is, their business is using software that was tested with the help of Mockito.  Some of these organisations are using Mockito 1.8.x, some 1.9.x and some 1.10.x.  Therefore, among the software developers in my city, there is quite a bit of existing expertise in these versions of Mockito.

My understanding is that Mockito 2.0 contains many breaking changes.  This will be a serious disincentive to any of these organisations to upgrade.  It can actually be quite expensive for an organisation to have a developer work out why a whole load of unit tests are suddenly failing, and fix them all up.  And this is a difficult expense to justify to management, especially when Mockito 2.0 doesn't actually deliver too many exciting changes.  

Therefore, my advice to any organisation in my city that's using Mockito with Java 6 or 7 will be "upgrade to the highest available version of Mockito 1, but forget about Mockito 2".  My advice to any organisation that uses Java 6 or 7 and is contemplating using Mockito will be "use the highest available version of Mockito 1, because that way, you'll easily be able to find developers who are already expert in this".

For organisations using Java 8, of course, Mockito 3 will be a must.  But my point is, I can't think of any circumstance where it would be a good idea for an organisation to use Mockito 2.  And if Mockito 3 will contain breaking changes over Mockito 2, I can't imagine any organisation having much appetite for dealing with Mockito-related breakages twice.

As a professional developer who uses Mockito in the real world, my sincere recommendation to the Mockito team would be to STOP working on Mockito 2.0, and put all your effort into the Java 8 version of Mockito instead.

[Rafael Winterhalter]

Hi David,

thank you for your concern; however, I strongly disagree with your assertion. I freelance myself and I think that we all use Mockito "for real", that is what brought us to contributing after all. I very much understand that companies are hesistant towards costly migratations also because of the potential errors they carry along. And if we had introduced any subtle behavioural changes in Mockito 2, this would be something to worry about. Instead, the few changes within the mostly internal APIs will be compiler checked with an easy migration path. As long as you have not abused the framework too much, you will most likely not have to change a bit when upgrading. I just checked in one of our larger projects with over 8000 tests that depend on Mockito and I could switch from 1.10.19 to the latest 2 beta without a single problem. The reason that we have not done this yet is the "beta" label that scares (cooperate) people away.

As for software changes: most organizations have learned how to migrate software. Spring constantly changes APIs; the 0.9 Kafka driver has built an entire new API compared to the 0.8 driver. It is sort of a developer's job to deal with breaking software updates on a regular basis. And with a testing framework, we have the opportunity to not break any dependencies as few people declare dependencies that import a different version of Mockito transitively; everybody can update at their own pace. The release will surely keep some people occupied but I still think that many of the bug fixes (that partly required breaking changes in their nature) can outweight the negatives of having to slightly update someone's software.

Of course, upgrading tests is no fun but upgrading a library where their API is also used in a test emposes the same problem set. Even worse, a developer has to figure out if the test broke or if the update failed at this point. (This makes mutation testing a great addition to writing normal tests.) And as another point, Mockito 1.* will most likely stop working on Java 9 as cglib cannot support Jigsaw modules in their current implementation. Porting such changes would again require breaking APIs even if we avoided it today. Changing things is just the nature of software. The tricky part is to keep things in proportion and I think Mockito 2 did a great job here.

As a matter of fact, many of my customers already run Mockito 2.* for the improved Java 8 support and I have not heard any complaints.

Cheers, Rafael

[Marcin Grzejszczak]

Hi!

I can't agree with Rafael more. I've joined the Mockito team recently and didn't have much time to help the guys but from what I see they have done until now a fantastic job with the approaching Mockito 2.0 release.

David, I've been working in companies that have been using Mockito "for real" (if in Pivotal for Spring Cloud we are using Mockito - are we using it "for real" or not? ;) ) and we had thousands of tests. We've been upgrading frameworks by major versions constantly of necessary. Your attitude is bizarre because you would expect the Mockito developers to have eternal backwards compatibility. It is unmaintainable! When developing a library some initial assumptions are made but eventually the library progresses. When I was working on Spring Cloud Sleuth - the iniitial snapshot version, the first milestone and the first GA versions were completely different. And I already know now that the next big release will most likely change some stuff in terms of the API. That is normal.

Also your argument that one shouldn't change a library because there are people who are experts in it is also bizarre. That way you could do only one release. And also what are we talking about? Mockito is relatively small and is extremely simple. The problem is not with the ability to use Mockito but with the ability to write good tests. If your colleagues know how to write good tests I'm pretty sure that they will spend an hour on checking out what new stuff came with Mockito 2.0.

Also you are refering to organizations that are using Java 6 and 7. As a professional developer who uses Mockito (and other libraries) in the real world, my sincere recommendation to any such team would be to STOP working on any business features until Java version gets upgraded. My advice to them is to upgrade cause those versions are no longer maintained. Actually one is asking for trouble if he doesn't do so. 

Cheers,

Marcin

[Szczepan Faber]

Guys, you're amazing!!!!

Thanks for pushing forward the release.

Lets set the release date to 8/30 (I'll tidy the stuff I started with
JUnitRule / Listener).

After next release, I plan to step down and let you run the show. It
seems I'm not finding enough time these days.

Cheers!

Szczepan Faber
Founder @ mockito.org | Twitter @ szczepiq
Author @ https://www.linkedin.com/today/author/6016386

[Tim van der Lippe]

I would prefer not to postpone the deadline even more.

If you are not able to finish the listener setup we can publish that fully in Mockito 2.1 instead.

Also sad to see you go, but understandable with your workload.

Regards,

Tim

Op vr 17 jun. 2016 om 06:02 schreef Szczepan Faber <szcz...@gmail.com>:

[Szczepan Faber]

Sounds good!

On Fri, Jun 17, 2016 at 12:56 AM, Tim van der Lippe

[Brice Dutheil]

Hey Szczepan,

Regarding this comment 

> Lets set the release date to 8/30 (I'll tidy the stuff I started with JUnitRule / Listener).

Do have an idea if you want to break the public API between a 2.0 and a 2.1 ?

-- Brice

[Brice Dutheil]

By the way on issue https://github.com/mockito/mockito/issues/123

• There’s a mention of serialVersionUID what do you meant at that time ?
• Regarding the incubating API, I still think most of the API should still have some warning, maybe with a @Beta marker. Thoughts ?

— Brice

[Szczepan Faber]

Just saw this message :)

>Do have an idea if you want to break the public API between a 2.0 and a 2.1?

Please, _please_, let's not break any API in minor versions. That's a
very bad signal to the clients showing that we don't honor semantic
versioning.

It's ok to consciously and cautiously break @Incubating APIs in minor versions.

>There’s a mention of serialVersionUID what do you meant at that time ?

I meant to kill all "serialVersionUID" from code. They don't add value
and are not consistently applied / used.

Cheers!