[Qgis-developer] Release schedule discussion - again

[Lauri Kajan]

Hi all,

Now each LTR release is not that different from regular releases. Those
LTR releases don't get that much more testing than other releases and
the .0 releases are potentially as fragile as regular releases.
It is mostly the new features that cases bugs and crashes. What if we
don't introduce any new features in LTR releases?
This is just a thought and I don't know if it would work in practice.

Let me explain better what I mean with this.
Basically the last point release would come the next LTR-release. We could
still have three releases per year. If I use ubuntu release
notation those are 15.02, 15.06 and 15.09. The next LTR would be
released in February of 2016 and that would be based on 15.09.2
for example. Lets name that release just LTR 16.
With this release process each new feature in LTR would have gone
through a three months testing during the usage period of 15.09 besides
the 15.09 feature freeze testing.
At the same time a regular 16.02 release could be released with all new
fancy features. Actually this would make four releases per year + point
releases.

Is this kind of process proposed before?
Like I said before I don't know how would this work in practice because I
can't imagine all different bug fixing, back porting or packaging
situations.



Regards,

Lauri

On Tue, Oct 13, 2015 at 9:46 AM, Paolo Cavallini <cavallini at faunalia.it>
wrote:

> Hi all,
>
> Il 13/10/2015 01:14, Tom Chadwin ha scritto:
> > If the devs need more end users to test, then changing to a release every
> > six months, LTR every two years, would help. However, how would the devs
> > feel about patching LTRs for twice the duration they do now, and for one
> > extra non-LTR in between each? To me it sounds like significantly more
> work
> > to keep backporting for two years instead of one.
>
> the current LTR has been an experiment, and IMHO it has been a success.
> Do we really want to change schedule every 6 months?
> We know for sure there are contrasting needs, and we'll never make
> everyone happy. Some times ago, we had people complaining not being able
> to use for many months the supercool feature they have developed or paid
> for.
> I think it's mostly a matter of communicating appropriately:
> * for maximum reliability, use the LTR
> * if you need latest features, go for the latest published.
> Maybe we should state this clearly on the download page.
> On the other hand, I am with Nyall on the Qt5 (and I should add Python
> 3) issue.
>
> More below.
>
> Il 12/10/2015 23:17, Larry Shaffer ha scritto:
>
> > At Boundless we are seeing both sides of the issue: users who want only
> > the LTR and users who deploy the LTR but always work with or test the
> > latest version between deployments of the LTR. The latter group is
> > finding the current pace quite difficult to keep up with. I'm talking
> > about very large government agencies rolling out to 100s upon 100s of
> > thousands of users. They rely upon the advice of their power users who
> > are working with whatever is the current version (not just the LTR).
>
> This touches a *very* imprtant point: large organisations should have
> very clear that if they need a more stable release cycle, the best and
> most clever thing they should do is to fund:
> * more automated tests
> * more backfixing
> * more and earlier backporting.
> I cannot believe someone using any software in such huge numbers not
> having a few hundreds thousands bucks to properly support these needs.
>
> All the best.
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> All the best.
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20151013/1084e921/attachment-0001.html>