Working on two versions in parallel

[Nikolaj Hald Nielsen]

> One of our problems with 2.2.2 currently is that we're in string (and
> feature) freeze, so many patches, ideas, and Merge Requests are on
> hold. What if we created a 2.2.3 branch, and started to work on two
> versions in parallel, before 2.2.2 is actually tagged?

I don't think this is a good idea for a couple of reasons.

What would happen is the same that always happens when we have a
stable branch and a "fun" feature branch. We are all suckers for cool
new features, so the feature branch is what everyone will end up
running, meaning that there is less focus on fixing bugs in the stable
branch and less overall testing of it.

Furthermore, I really don't think that this would solve any issues
that are not currently solved by git feature branches. I already have
a few feature branches for post 2.2.2 stuff. There are a few benefits
of using a branch for each feature instead of one big playground
branch. First of all, it allows you to work on an isolated feature for
as long as it takes to get it ready. You do not have to commit to
getting it into a specific release target when you start working on it
(as opposed to your idea where you would still have at most 6 weeks, 2
weeks while stable branch is in freeze and 4 weeks until the
playground branch becomes the new stable branch and is frozen, to work
on a feature). Also, and perhaps most importantly, even when working
on a branch that focuses on just one feature, you are still regularly
syncing it with master, meaning that you are still contributing
testing to master, even when working on your own branch. This would be
much harder on a shared "playground" branch as it ould quickly start
to deviate more from master. I know I often find issues this way,
switch back to master to fix it, push and then update my branch to get
the fix.

Just my 2 cents.

- Nikolaj