[Qgis-developer] The case for bugfix releases
larrys at dakotacarto.com
Mon Sep 30 13:41:27 PDT 2013
On Mon, Sep 30, 2013 at 12:26 PM, Radim Blazek <radim.blazek at gmail.com>wrote:
> On Mon, Sep 30, 2013 at 8:53 AM, Sandro Santilli <strk at keybit.net> wrote:
> > On Mon, Sep 30, 2013 at 08:22:59AM +0200, Paolo Cavallini wrote:
> >> Il 29/09/2013 12:48, J￼rgen E. Fischer ha scritto:
> >> > Anyway, this this is not yet set in stone as I'm currently still
> sorting out
> >> > stuff related to the 2.0 release (e.g. in OSGeo4W) - and therefore
> didn't have
> >> > time to come with draft for this. So when this actually starts is
> still TBD.
> >> IMHO the new approach from Juergen should solve most of our problem. I
> >> people may need even more frequent (monthly) backporting of fixes. The
> only way I see
> >> this may become possible is to fund a small team of dedicated
> backporters, that can
> >> also take care of the prodction of binaries.
> > I think frequent releases mixing features and bugfixes are not going to
> > help those whose need is stability.
> Agreed, important in this discussion.
And very important to the reputation of the whole project. We are now
seeing the effects of telling users/reporters they need to wait until the
next release for bug fixes. I propose a compromise, of sorts, which offers
the advantages of the approach noted by Juergen and a focus on backporting
to a stable branch.
The problem is that while feature, API, GUI and string freezes are mandated
leading up to a release (towards the obvious goal of stability), once 2.0
was tagged for released, for example, the flood gates were again opened on
master branch and new features came pouring in. This makes quick
backporting of fixes to a stable branch much more difficult, and
exponentially so as time goes on. I think this is the root cause of discord
between users/reporters and developers: it gives the appearance that the
release branch is now abandoned and/or that the developers are not
concerned with stability.
A possible solution is to have a 'release freeze' period that extends the
freezes reasonably beyond the package releases, with devs strictly focusing
on addressing immediate issues with the current release, committing the
fixes to master branch. Any timely fixes can quickly be ported (maybe just
easily cherry-picked) between branches. For 2.0, this would have markedly
slowed feature improvements to master branch for many weeks, but greatly
helped towards stability. After a period of time (depends upon issues), a
bug-fix release is tagged for packaging, the freezes are lifted, and a
backporting team, hopefully funded, continues work on maintaining the
release branch, while devs go back to focusing on making QGIS better.
For future releases, with quicker release frequencies, the freeze period
after a release may not be that long at all. A worthy trade-off IMHO,
towards stable releases and not causing a backporting hell scenario.
Essentially, I think we, as developers, need to take more step towards the
stability of releases, after they are released, which equates to
maintaining the reputation of the project.
> > Stability needs bugfix _only_ releases
> > as _any_ new feature mines the stability of the software.
> We all know that, I think, just nobody has time to maintain bugfix
> branch. As Paolo pointed out above, backporters have to be paid. I am
> sure that for most sponsors the stability is of high importance, so
> let some part of sponsorship is regularly used to pay maintenance of
> bugfix branch and releases.
> BTW, the reason it took so long to get out 2.0 was API change, we
> don't want to break API too frequently but takes long time to get
> larger API changes stable. This will happen with 3.0 again.
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Qgis-developer