2 concurrent dev branches

[Szczepan Faber]

Hey,

Currently, we have 2 concurrent dev branches. Master 3.0 beta + release/2.x. This style is expensive and may bite as merges get harder.

Some options:

 - continue with 2 branches...

 - freeze development of 3.0 until next year (perhaps make release/2x alias master)

 - separate jar for java8

Thoughts?

--

Szczepan Faber

Founder @ mockito.org | Twitter @ szczepiq

Author @ https://www.linkedin.com/today/author/6016386

[Tim van der Lippe]

At this moment I do not see any problems with the current workflow, features are compatible for both Mockito versions. We can merge all of the features from release/2.x to master, but not vice versa. Therefore all features that do not require Java 8 must be merged into release/2.x first.

Op zo 9 okt. 2016 om 04:29 schreef Szczepan Faber <szcz...@gmail.com>:

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

[Szczepan Faber]

There is an extra cost in managing merges. There is an extra risk when devs forget to merge.

[Brice Dutheil]

This is not really expensive got merges are a breeze. Also this enable the team and contributors to work on different things. 

The 2.x is a release branch that is not supposed to live forever. Usually these branches are post release fixes. In the case of mockito we scoped out items of 2.1 to make the release happen. And allow us to continue develop scoped out feature of mockito 2. Meanwhile master is the next mockito, once scope of 2.2 is over we won't have to merge as often.

So let's continue with 2 branches.

-- Brice

_____________________________
From: Szczepan Faber <szcz...@gmail.com>
Sent: Sunday, October 9, 2016 23:07
Subject: Re: [mockito-dev] 2 concurrent dev branches
To: <mocki...@googlegroups.com>

[Szczepan Faber]

Hmmm, maybe.

Who's responsible for merging? :)

Also, when external contributor submits PR to 2.x, who is responsible for merging to 3.x?

[Szczepan Faber]

Personally, till next year I want to focus on adding new features to 2.x and make Mockito 2 story even more compelling (richer stubbing API, better strict mock support, unmockable support).

Does Mockito 3.0 have to be incompatible with 2.0? Can we make it so that if someone already uses Java 8 he can change 2.x -> 3.0 and everything works?

Given work needed in 2.x, I'd rather we do it on master, create release/3.x that does not publish any betas. We use Tim's cool idea and offer a way to publish experimental versions on demand via commit message. We can follow your idea to push experimental versions to non-default repositories for limited visibility.

Pushing beta version for every change does not make sense - those are not beta versions but simply current work in progress.

cc Marcin as he works on his CD presentation :)

Thoughts?

[Brice Dutheil]

Who’s responsible for merging? :)

The guy that merged the PR.

Does Mockito 3.0 have to be incompatible with 2.0? Can we make it so that if someone already uses Java 8 he can change 2.x -> 3.0 and everything works?

Yes Java 8, removal of some API, addition of some others, maybe behavior changes. In practice this is not really a problem, git is quite intelligent, merging regularly is important though.

Given work needed in 2.x, I’d rather we do it on master, create release/3.x that does not publish any betas.

That’s wrong ! I’m opposed to that. The idea of release branch per version is to have allow to add remaining features or bug fix stuff of that release version that couldn’t ship before ; that was the plan of 2.2 that we established in the first semester. master can undergo much more massive change.

Pushing beta version for every change does not make sense - those are not beta versions but simply current work in progress.

Our 2.x betas were work-in-progress, naming aside, the CD released them. And work-in-progress is by definition an incomplete work, why would we want to deliver incomplete work not labeled as such SNAPSHOT, alpha, etc.

— Brice

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.

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

--

Szczepan Faber

Founder @ mockito.org | Twitter @ szczepiq

Author @ https://www.linkedin.com/today/author/6016386

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

--

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.

--

Szczepan Faber

Founder @ mockito.org | Twitter @ szczepiq

Author @ https://www.linkedin.com/today/author/6016386

--

Szczepan Faber

Founder @ mockito.org | Twitter @ szczepiq

Author @ https://www.linkedin.com/today/author/6016386

--

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.

​

[Marcin Zajączkowski]

On 2016-10-10 01:46, Szczepan Faber wrote:
> Personally, till next year I want to focus on adding new features to 2.x
> and make Mockito 2 story even more compelling (richer stubbing API, better
> strict mock support, unmockable support).
>
> Does Mockito 3.0 have to be incompatible with 2.0? Can we make it so that

IMHO it could be hard to remain backward compatibility with Java 7 and
use Java 8 feature. The initial idea of a separate module was in
AssertJ. In the end it turned out that some features are not feasible to
implement that way (and there are currently 2 separate branches). Maybe
in Mockito it would be somehow easier, but even with simple features
(like Java 8 types which are currently used) the reflection needs to be
used which is not very nice.

> if someone already uses Java 8 he can change 2.x -> 3.0 and everything
> works?
>
> Given work needed in 2.x, I'd rather we do it on master, create release/3.x
> that does not publish any betas. We use Tim's cool idea and offer a way to
> publish experimental versions on demand via commit message. We can follow
> your idea to push experimental versions to non-default repositories for
> limited visibility.

The initial idea (one of) was to finish 2.0 (named 2.1) and focus on
3.x. However, currently there are not many PRs related to Java 8 only.
Szczepan suggested adding new features to the 2.x line. Maybe it makes
sense, but on the other hand AFAIR one of the biggest arguments to keep
Mockito 2.0 Java 7 compatible was to not leave Java 7 project with quite
old Mockito 1.x. Currently there is 2.1 available, so maybe it would be
less problematic to add new features only to Mockito 3 which will be
Java 8+ and maybe cherry-pick so changes to Mockito 2.x is really needed
(together with serious bug fixes).

On the other hand, personally I'm not convinced to any particular
solution. If you guys see a need to have more features available in 2.x
for me would be good to mark is as a default target for PRs and focus
the work on 2.x merging (not cherry-picking), even occasionally (not
every one PR) changes from 2.x to 3.x branch (probably still named
master). It should be relatively easy to maintain up until really
incompatible (and conflicting) changes are introduced in the 3.x line.
However, in that case there would have to be a mechanism to
automatically release versions for 3.x, even if marked as
alpha/beta/wip/whatever, even if pushed to a separate repo to provide a
change to test them by people (as it can take some time to have 3.0.0
released).

In the end I'm probably closer to the things that Brice proposes.

Marcin

http://blog.solidsoft.info/ - Working code is not enough

[Tim van der Lippe]

I think we should strive for backwards-compatible features and therefore first merge into release/2.x. However if there are features that are only Java 8 compatible (e.g. the new when syntax) then we need to merge just in 3. Therefore every single change of 2.x must be merged into 3, but not vice versa. We as the developers have to take care of this process.

Op di 11 okt. 2016 om 01:53 schreef Marcin Zajączkowski <msz...@wp.pl>:

[Brice Dutheil]

Therefore every single change of 2.x must be merged into 3, but not vice versa.

This is the safe and sane way to go ; git wise or development wise.

Additionally a sane git workflow for the code would be :

• Merge release/2.x to master, because every or almost every feature of 2.x should be available in the next version
• Don’t merge master to release/2.x, this mixes the history the wrong way.
• Cherry-pick changes of master to release/2.x only if this is an important fix that should be backported.

Almost no-one expects a library to backport every thing from the latest version to the previous. Git offers a lot of flexibility and it allows to support many different workflows from the most complicated to the most stupid. I don’t want to use Git as SVN/CVS, and I don’t want to have Linux kerne workflow, I think the workflow described above is quite simple to follow.

That’s what we have currently.
— Brice

​

[Szczepan Faber]

Thanks guys for feedback!

Adding features to release/2.x and constantly merging them to master is an extra effort but let me first feel it before I make an action to fix it :)

@Brice, thanks for describing the process, it is very clear.

Cheers!

--

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]

Adding features to release/2.x and constantly merging them to master is an extra effort but let me first feel it before I make an action to fix it :)

That’s why we don’t want to constantly update 2.x, we only want to update 2.x for the remaining items that couldn’t be shipped in 2.x. Actually I’m even more in favor of moving some of this tasks to 3.x e.g. master.

— Brice

On Tue, Oct 11, 2016 at 4:16 PM, Szczepan Faber <szcz...@gmail.com> wrote:

Thanks guys for feedback!

Adding features to release/2.x and constantly merging them to master is an extra effort but let me first feel it before I make an action to fix it :)

@Brice, thanks for describing the process, it is very clear.

Cheers!

On Tue, Oct 11, 2016 at 7:01 AM Brice Dutheil <brice....@gmail.com> wrote:

Therefore every single change of 2.x must be merged into 3, but not vice versa.

This is the safe and sane way to go ; git wise or development wise.

Additionally a sane git workflow for the code would be :

• Merge release/2.x to master, because every or almost every feature of 2.x should be available in the next version
• Don’t merge master to release/2.x, this mixes the history the wrong way.
• Cherry-pick changes of master to release/2.x only if this is an important fix that should be backported.

Almost no-one expects a library to backport every thing from the latest version to the previous. Git offers a lot of flexibility and it allows to support many different workflows from the most complicated to the most stupid. I don’t want to use Git as SVN/CVS, and I don’t want to have Linux kerne workflow, I think the workflow described above is quite simple to follow.

That’s what we have currently.
— Brice

​

--

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.

--

Szczepan Faber

Founder @ mockito.org | Twitter @ szczepiq

Author @ https://www.linkedin.com/today/author/6016386

--

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.

​