Working on two versions in parallel

[Nikolaj Hald Nielsen]

Addendum:

I just had a few more thoughts.

The only case where I think this proposal would make sense is if we
adopt a release scheme more similar to that of KDE SC itself and then
keep the fast releases "bugfix only". Although I might have been a
proponent of this previously, I currently thing that the 6 week
release schedule is worth holding on to for a while at least. It has
the great benefit of forcing people to not start big new fetures that
they cannot finish in a sane time frame, meaning that we do not have
the huge cleanup phases that we had leading up to 2.0.0, 2.1.0 and
2.2.0 where we again and again had to push back the releases since so
many of us had added things that were only 90% complete.

- Nikolaj



On Wed, Dec 9, 2009 at 11:53 AM, Nikolaj Hald Nielsen
<nhnfreespirit at gmail.com> wrote:
>> 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
>