Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Release planning

On 2017-05-16, 3:19 PM, "cdt-dev-bounces@xxxxxxxxxxx on behalf of Nathan
Ridge" <cdt-dev-bounces@xxxxxxxxxxx on behalf of zeratul976@xxxxxxxxxxx>

>> I have found having two active branches and having to backport
>> bugfixes to the old branch (which I want to do, to get bugfixes in
>> front of users sooner) to be a fair deal of overhead
>This also means that *if* we're going to have a 9.4 release for
>Oxygen.1, it would be good to decide that now (or by the time
>9.3 branches), so that we don't waste time backporting fixes
>to the 9.3 branch in that case.

+1 We don¹t have the capacity to have two active branches. So I¹m all for

We could look at it another way. Let¹s say the maintenance releases are
for hot fixes only. Things that users are really complaining about.
Hopefully there are only a few of those. Regular bugs would go on master
only. And we would release the hot fixes any time, just as we did for
9.2.2. We would just roll up the latest hot fix release in with Oxygen.1.

I still worry whether we have the capacity to do features at three month
intervals and whether our users and vendors have the capacity to deal with
new feature releases that often. I just feel six months is more practical
and is a common cadence we see in other projects (e.g. Ubuntu). But I can
be persuaded by your (the committers') confidence in making it work :)

>cdt-dev mailing list
>To change your delivery options, retrieve your password, or unsubscribe
>from this list, visit

Back to the top