Is it still planned for 2.0 to give users an option to use an alternative to cglib (like Byte Buddy)?
 This kind of feature can be added any time (e.g. it's not a backwards-incompatible change). It's just someone needs to implement it :) 

So short answer is 'no', it's not planned for 2.0 (but I would love to have this feature soon)
 If possible I would really like to replace CGLIB by bytebuddy.

I wanted to craft an external MockMaker but I'm way too much overwhelmed at the moment. The code exists in my clone though.
 @bric3, you mean that you're keen on changing default proxy mechanism in 2.0? I'm fine with this :) I do want to publish 2.0 this year though and I won't be very active it this part of the code. So, if you make it, it can be included :)
 @szczepiq You mean by the end of 2014 ?

What I hoped was to build a mockmaker that could be tested on the 1.x. But the code may replace CGLIB now if necessary. Beta have to be tested by other people though, I especially think about uncommon environment like OSGI, etc...
 1>You mean by the end of 2014 ?

haha, yeah ;)

> What I hoped was to build a mockmaker that could be tested on the 1.x.

Like an opt-in feature for 1.x?

I definitely think that given we have the bytebuddy impl of MockMaker, we
should make it conveniently pluggable instead of just replacing cglib
completely. You mentioned earlier that you had the ByteBuddy MockMaker
working with Mockito test suite?

Cheers!

On Mon, Nov 24, 2014 at 4:18 PM, Brice Dutheil notifications@github.com
wrote:

> You mean by the end of 2014 ?
> 
> What I hoped was to build a mockmaker that could be tested on the 1.x. But
> the code may replace CGLIB now if necessary. Beta have to be tested by
> other people though, I especially think about uncommon environment like
> OSGI, etc...
> 
> ## 
> 
> Reply to this email directly or view it on GitHub
> https://github.com/mockito/mockito/issues/123#issuecomment-64208043.

## 

Szczepan Faber
Core dev@gradle; Founder@mockito
 > > What I hoped was to build a mockmaker that could be tested on the 1.x.
> 
> Like an opt-in feature for 1.x?

Yes. But, meanwhile replacing CGLIB in mockito 2.0.

> You mentioned earlier that you had the ByteBuddy MockMaker working with Mockito test suite?

Yes it does. I just would like to ensure it works with uncommon environment like OSGI.
 Do you think it is worthwhile to keep support for cglib once we have
bytebuddy?

Do you think we should shade bytebuddy? What dependencies bytebuddy brings?

On Mon, Nov 24, 2014 at 6:26 PM, Brice Dutheil notifications@github.com
wrote:

>  What I hoped was to build a mockmaker that could be tested on the 1.x.
> Like an opt-in feature for 1.x?
> 
>  Yes. But, meanwhile replacing CGLIB in mockito 2.0.
> 
> You mentioned earlier that you had the ByteBuddy MockMaker working with
> Mockito test suite?
> 
> Yes it does. I just would like to ensure it works with uncommon
> environment like OSGI.
> 
> ## 
> 
> Reply to this email directly or view it on GitHub
> https://github.com/mockito/mockito/issues/123#issuecomment-64229927.

## 

Szczepan Faber
Core dev@gradle; Founder@mockito
 No I don't think it is necessary, however we can make a CGLIB mock maker, for people that may depend on it.
 I am curious: Do you guys have a time-line for the 2.0 release? I am more than happy to support any code-generation releated issues. However, my vacation is approaching so I will be gone for a couple of weeks starting mid-August.

In particular, I wonder you guys wanted to try integrating Byte Buddy 0.7 with support for generic type retention already in 2.0 which I hope to complete before my vacation. One word of warning: Generic types are awefully complex. Byte Buddy needs to parse stringified type information and resolve the full type hierarchy, i.e. bind type variables of super types / interfaces to their actual values in order to appropriately resolve a type variable's value while dealing with the possibility of raw types and potentially illegally formatted generic types (the JVM does not verify generic type infromation which simply exists as meta data). There is a chance for corner case errors even though I isolated the functionality pretty much to fall back to type erasure if any illegal type information is disovered. At the same time, mocks would behave better when a generic type is read by a class processing a mock.
 It must happen in 2015. I hope we are ready in the next few months. In
theory, there's not much left work :)

Cheers!

On Fri, Jul 10, 2015 at 5:31 AM, Rafael Winterhalter <
notifications@github.com> wrote:

> I am curious: Do you guys have a time-line for the 2.0 release? I am more
> than happy to support any code-generation releated issues. However, my
> vacation is approaching so I will be gone for a couple of weeks starting
> mid-August.
> 
> —
> Reply to this email directly or view it on GitHub
> https://github.com/mockito/mockito/issues/123#issuecomment-120399539.

## 

Szczepan Faber
Founder mockito.org; Core dev gradle.org
tweets as @szczepiq; blogs at blog.mockito.org
 I think mockito 2.0 is nearly in shape to be released, most work should go in polishing remaining bits of the public API. IMHO current byte buddy version is fine, and already provide subtitle but needed enhancements.

More specifically on generics I believe current support is OK, after all mockito is a TDD tool for a rapid feedback loop, both on the dev workstation and the ci bots. I believe current generics support in the deepstubs answer is enough. About the issue you mention the support class I wrote is probably incomplete but enough, and I agree parsing this metadata is hard. Anyway at the moment if any extended support should be provided on this front it should be provided via a mockmaker plugin.
 Thanks for the info. I just released Byte Buddy 0.7 but I recommend you to not yet update. Generic types are tricky and I already found a corner case in the bridge method resolution that does not work. I'll try to make it stable until the mid of August, though.
 Any guess on when 2.0 will be released?
 It's been silent for past couple of months, everybody busy, etc. Since
yesterday, I'm focusing my spare time on Mockito. I will not stop until 2.0
is out. We cannot guarantee any dates but 2.0 must be released in 2015.

On Sat, Sep 19, 2015 at 8:40 AM, David J. M. Karlsen <
notifications@github.com> wrote:

> Any guess on when 2.0 will be released?
> 
> —
> Reply to this email directly or view it on GitHub
> https://github.com/mockito/mockito/issues/123#issuecomment-141681244.

## 

Szczepan Faber
Founder mockito.org; Core dev gradle.org
tweets as @szczepiq; blogs at blog.mockito.org
 Any updates on when we might see a 2.0 release?
 2015 is soon over ;) At some point, we need to do a cut in features. I think everybody is quite budy right now. As always, the time before Christmas are busy month for consultant work.
 Soon. This year for sure. Sorry I was distracted! We will probably deliver
2.0 with what we have, no new fancy features ;)
On Nov 10, 2015 4:52 AM, "Rafael Winterhalter" notifications@github.com
wrote:

> 2015 is soon over ;) At some point, we need to do a cut in features. I
> think everybody is quite budy right now. As always, the time before
> Christmas are busy month for consultant work.
> 
> —
> Reply to this email directly or view it on GitHub
> https://github.com/mockito/mockito/issues/123#issuecomment-155412454.
 Can this task https://github.com/mockito/mockito/issues/300 be included in 2.0 release?
 Feel free to add #374 to the todo list
 2.0  is coming so slow.
 It's way too slow. I'm on it. Thank you guys for pushing.
 @szczepiq How can we/the community support the mockito core team ?
 > @szczepiq https://github.com/szczepiq How can we/the community support
> the mockito core team ?
> 
> You already are. You guys are great. Thank you for patience and pushing us
> to deliver.

The lagging of beta is my fault. I've started the beta cycle and I should
have completed it. I'm back in the game, though.

Once 2.x final is out we need clarify how community can drive supporting
and maintaining Mockito.

Note that Mockito is continuously delivered so you can open PR to change
the version to "2.1.0", and that's it :)

Cheers!

> —
> You are receiving this because you were mentioned.
> Reply to this email directly or view it on GitHub
> https://github.com/mockito/mockito/issues/123#issuecomment-206757516
 @szczepiq I left a pull request for removing deprecated code which is an 2.0 milestone issue - can you pull it/looks good?
 I haven't reviewed yet. THANKS!
On Sun, Apr 10, 2016 at 03:12 David J. M. Karlsen notifications@github.com
wrote:

> @szczepiq https://github.com/szczepiq I left a pull request for
> removing deprecated code which is an 2.0 milestone issue - can you pull
> it/looks good?
> 
> —
> You are receiving this because you were mentioned.
> Reply to this email directly or view it on GitHub
> https://github.com/mockito/mockito/issues/123#issuecomment-207953253
 Per Mockito developers discussion:

We want to target publishing the release on July 31st with a release candidate on June 30th.

There is one issue which must be resolved for that, which is #194. Other than that I just found 1 minor TODO [in the Mockito documentation](https://github.com/mockito/mockito/blob/dff5510cb3e97dae414e58ba85825ad01b273c72/src/main/java/org/mockito/Mockito.java#L1091). The other issues can be fixed in a later minor version.
 @TimvdLippe  what about https://github.com/mockito/mockito/issues/300?
 @skabashnyuk I think that we still want to do this, but is not a blocker for the release. We must do it when we have time, but it is okay in my opinion to release it in a later minor version. I have to be honest that I was not participating in the original discussion so I do not know the exact details. @bric3 is the man to talk to :)
 @TimvdLippe @skabashnyuk Humm I think we should really focus energy on mockito 2, TestNG could come later.
 > TestNG could come later.

@bric3 No problem. But why this can't be done in parallel? Code is ready, looks like this is an infrastructure-deployment issue. Or you are planning to do something bigger than just deploy artifacts?
 @skabashnyuk Currently we are focused on releasing Mockito 2.0. This leaves little to no time for other issues sadly. If you are able to configure the deployment, we are happy to accept your pull request! We can devote some of our time to the TestNG issue after we have released Mockito 2.0.
 Some update.

We're not ready for the release but there's good momentum. Let's plan out
what else needs to be done (announcement information, really documentation
around why to upgrade and how, solid plan what's next after the release
candidate, etc.).

I'm confident the RC will be out in August. I plan to announce everywhere
that we plan RB in August. If we don't meet the date there will high degree
of shame ;) Thoughts?

On Sat, Jun 25, 2016 at 3:59 AM, Tim van der Lippe <notifications@github.com

> wrote:
> 
> @skabashnyuk https://github.com/skabashnyuk Currently we are focused on
> releasing Mockito 2.0. This leaves little to no time for other issues
> sadly. If you are able to configure the deployment, we are happy to accept
> your pull request! We can devote some of our time to the TestNG issue after
> we have released Mockito 2.0.
> 
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> https://github.com/mockito/mockito/issues/123#issuecomment-228532419,
> or mute the thread
> https://github.com/notifications/unsubscribe/AABgp8m2jG-9Rj7USJ1V2s6GJNHLzbdwks5qPQodgaJpZM4C_fdm
> .

## 

Szczepan Faber
Founder @ mockito.org | Twitter @ szczepiq
Author @ https://www.linkedin.com/today/author/6016386
 I think most of the work should be focused on the upgrade guide, there's not much left for 2.0, follow up tasks can be completed in 2.1
 I think we can publish the release candidate while working on the actual upgrade guide (state this in the github release for users to follow). The only two issues that are non-documentation are #384 with PR #527 of @szczepiq and #489 with PR #491 of myself. #527 has some feedback to be processed and #491 is more of a discussion regarding the runner.

Once these two are resolved, we can merge #483 and the release candidate is published :tada: 

For an up-to-date status, see https://waffle.io/mockito/mockito and https://github.com/mockito/mockito/milestone/1
 This is great stuff!!! Thanks a lot Tim for pushing the release forward & organizing it so well.

I'm making good progress on the warnings stuff for JUnit rule and the listener - will update the PR very soon.
 I'm confused why this ticket is closed. I don't see 2.0 in maven central :)
 @szczepiq because this issue was referenced in #483 which I just merged
 ah, GH smartness :)
 As promised here’s suggested plan to get 2.0 out. Please give feedback, sing up for tasks and commit to ETA so that we get 2.0 out :)

Step 1:
- [ ] prepare RC release notes + announcement (highlights, motivation, request for feedback) - #582
- [ ] review and update documentation for 2.0.0 - #596
- [ ] ensure & test manual Mockito releases - #586
- [ ] update CI / build scripts (releasing betas from branch, etc) - #594

Step 2:
- [ ] branch out / fixes to release / Travis - #594

Step 3:
- [ ] pull the trigger for RC!!!!!, close darn #123 !!!!!!
 ![image](https://cloud.githubusercontent.com/assets/5948271/18092170/97fac1ca-6ecb-11e6-83e0-fd2953833359.png)
 I think we have updated all relevant documentation. @bric3 once you branch out to `release/2.x` we can publish the release candidate :tada: 
 I went ahead and published the release candidate. You can download `2.1.0-RC.1` at https://bintray.com/szczepiq/maven/mockito/2.1.0-RC.1#
 By the way I would prefer to have mockito account on bintray 
 Yes agreed. Let's extract a separate issue for that.
 Mockito 2.1.0 has been released, upgrade today :tada: 

Release Mockito 2.0
Incompatible changes:
- [x] stop producing mockito-all #153
- [x] stop depending on hamcrest internally #154
- [x] use newer hamcrest #232
- [x] make the anyXxx and any(Xxx) matchers intuitive #134, #194
- ~~fix the site links~~
- [x] push cglib mockmaker to a separate jar #248
- [x] stop using ant for producing OSGi bundles. No more ant in the build #249
- [x] remove jars from source distribution #250
- ~~perhaps introduce is() matcher~~ #246
- ~~richer and smarter stubbing~~ #303
- ~~support java8 features for capturing arguments and matchers~~
- [x] make the JUnitRule and the runner verbose
- [x] ensure release notes can be neatly generated for the RC #582

Possibly compatible (and hence, could be released pre-2.0 if needed)
- [x] drop deprecated code
- [x] unincubate API
- ~~drop serialVersionUID~~

README.md buildSrc/src/main/groovy/org/mockito/release/version/VersionBumper.java version.properties
README.md buildSrc/src/main/groovy/org/mockito/release/version/VersionBumper.java version.properties
buildSrc/src/test/groovy/org/mockito/release/version/VersionBumperTest.groovy
diff --git a/README.md b/README.md
index 1ffdd450c9..d3595e27fc 100644
--- a/README.md
+++ b/README.md
@@ -17,24 +17,34 @@ See the [release notes page](https://github.com/mockito/mockito/blob/master/doc/
 
 ## Versioning
 
-Mockito has an automated release system, which imposed some change on how the version numbers work. While this is similar to [_semver_](http://semver.org/), there's some differences. Let's look at the following versions `1.10.19` and `2.0.5-beta` and `2.0.0` (not yet released). They follow this scheme:
+Mockito has an automated release system, which imposed some change on how the version numbers work.
+They follow this scheme:
 
 ```
-major.minor.build-tag
+major.minor.patch-tag.tagVersion
 ```
 
 | number | meaning                                                                               |
 | ------ | ------------------------------------------------------------------------------------- |
-| major  | major version, with most probably incompatible change in API and behavior             |
-| minor  | minor version, important enough change to bump this number                            |
-| build  | a released build number incremented automatically when a pull request is merged       |
-| tag    | will probably be `-beta` or just nothing (during beta, breaking changes are expected) |
+| major  | major version, backwards incompatible with the previous major version                 |
+| minor  | minor version, backwards compatible with added features                               |
+| patch  | patch version, small bug fixes or stylistic improvements                              |
+| tag    | *optional* beta or RC (release candidate). See below.                                 |
 
 That means:
 
-* `2.0.0` and `2.0.5-beta` are binary incompatible with `1.10.19`.
-* `2.0.5-beta` is the fifth release beta of version `2.0.0`.
-* `2.0.5-beta` is a work in progress, api may change and may not be graduated in version `2.0.0`.
+* `2.0.0` and `2.0.0-beta.5` are binary incompatible with `1.10.19`.
+* `2.0.0-beta.5` is the fifth release beta of version `2.0.0`.
+* `2.0.0-beta.5` could be (but is not necessarily) binary incompatible with version `2.0.0`.
+* `2.0.0-RC.1` is binary compatible with release `2.0.0`.
+
+### Tags
+There are two different tags: beta or RC. Beta indicates that the version is directly generated from the master branch of the git repository.
+Beta releases are automatically published whenever we merge a pull request or push a change to the master branch.
+
+When we deem our master status worthy of a release, we publish a release candidate. The release candidate is scheduled to be officially published
+in the official release a while later. There will be no breaking changes between a release candidate and its equivalent official release.
+The only changes will include bug fixes or small updates. No additional features will be included.
 
 ## Looking for support
 
diff --git a/buildSrc/src/main/groovy/org/mockito/release/version/VersionBumper.java b/buildSrc/src/main/groovy/org/mockito/release/version/VersionBumper.java
index 01ed67cac5..b6f6ba8e54 100644
--- a/buildSrc/src/main/groovy/org/mockito/release/version/VersionBumper.java
+++ b/buildSrc/src/main/groovy/org/mockito/release/version/VersionBumper.java
@@ -9,17 +9,20 @@ class VersionBumper {
      * Increments 'patch' element of the version of provided version, e.g. 1.0.0 -> 1.0.1
      */
     String incrementVersion(String version) {
-        Pattern pattern = Pattern.compile("(\\d+)\\.(\\d+)\\.(\\d+)(-(\\w+)){0,1}");
+        Pattern pattern = Pattern.compile("(\\d+)\\.(\\d+)\\.(\\d+)(-(\\w+)\\.(\\d+))?");
         Matcher matcher = pattern.matcher(version);
         boolean m = matcher.matches();
         if (!m) {
-            throw new IllegalArgumentException("Unsupported version: '" + version + "'. Examples of supported versions: 1.0.0, 1.20.123, 1.0.10-beta");
+            throw new IllegalArgumentException("Unsupported version: '" + version + "'. Examples of supported versions: 1.0.0, 1.20.123, 1.0.10-beta.3");
         }
 
         int major = Integer.parseInt(matcher.group(1));
         int minor = Integer.parseInt(matcher.group(2));
         int patch = Integer.parseInt(matcher.group(3));
-        String postfix = matcher.group(4) != null ? matcher.group(4) : "";
-        return "" + major + "." + minor + "." + (patch + 1) + postfix;
+        if (matcher.group(4) != null) {
+            int betaVersion = Integer.parseInt(matcher.group(6));
+            return "" + major + "." + minor + "." + patch + "-" + matcher.group(5) + "." + (betaVersion + 1);
+        }
+        return "" + major + "." + minor + "." + (patch + 1);
     }
 }
diff --git a/version.properties b/version.properties
index 3d70180266..d87a336523 100644
--- a/version.properties
+++ b/version.properties
@@ -1,2 +1,2 @@
-version=2.0.112-beta
+version=2.0.0-beta.112
 mockito.testng.version=1.0

diff --git a/buildSrc/src/test/groovy/org/mockito/release/version/VersionBumperTest.groovy b/buildSrc/src/test/groovy/org/mockito/release/version/VersionBumperTest.groovy
index db1c3d6835..b34bcda696 100644
--- a/buildSrc/src/test/groovy/org/mockito/release/version/VersionBumperTest.groovy
+++ b/buildSrc/src/test/groovy/org/mockito/release/version/VersionBumperTest.groovy
@@ -13,8 +13,9 @@ class VersionBumperTest extends Specification {
         v.incrementVersion("0.0.0") == "0.0.1"
         v.incrementVersion("1.10.15") == "1.10.16"
 
-        v.incrementVersion("1.0.0-beta") == "1.0.1-beta"
-        v.incrementVersion("1.10.15-beta") == "1.10.16-beta"
+        v.incrementVersion("1.0.0-beta.3") == "1.0.0-beta.4"
+        v.incrementVersion("1.10.15-beta.5") == "1.10.15-beta.6"
+        v.incrementVersion("2.0.0-RC.1") == "2.0.0-RC.2"
     }
 
     def "increments only 3 numbered versions"() {
@@ -25,6 +26,6 @@ class VersionBumperTest extends Specification {
         thrown(IllegalArgumentException)
 
         where:
-        unsupported << ["1.0", "2", "1.0.0.0", "1.0.1-beta.2"]
+        unsupported << ["1.0", "2", "1.0.0.0", "1.0.1-beta"]
     }
 }
