Nightly builds (or weekly snapshots for that matter) are very different
from a publicized, pre-release preview build. With a prepared pre-release
preview, users are at least expecting that basic functioning will work,
that's something the nightly builds simply can't guarantee by the nature
of
-but you get an higher chance of getting a broader number of people (that
interacts with QGIS in different ways) to test out your product before it's
released.
+but you get an higher chance of getting a broader number of people (that
interacts with QGIS in different ways) to test out your product
Hi Mathieu,
On Mon, 24. Feb 2014 at 15:42:19 +0700, Mathieu Pellerin wrote:
Nightly builds (or weekly snapshots for that matter) are very different
from a publicized, pre-release preview build. With a prepared pre-release
preview, users are at least expecting that basic functioning will work,
Why not? We're talking about a feature freezed period!? The nightly
build
is a snapshot what what will get release. Where do you see a difference?
I think it's a perception thing.
Nightly build in my mind always means bleeding edge may or may not work,
use at own risk. I'm aware that
How about making a formal announcement (mailing list, website, wiki etc)
telling the users that QGIS version 2.X is in feature freeze and therefore
is sufficiently stable to be tested by end users? This may increase the
number of testers.
As an end user that uses QGIS for production, this is the
Slightly deviating from the topic, but I'm quite fond of the GeoServer
release process; they're revamping a little to offer better Long Term
Support:
http://geoserver.org/display/GEOS/GSIP+107+-+Extended+Release+Schedule
I feel a similar system would solve most of QGIS' release problems:
- Bugfix
Hi Jonathan,
On Mon, 24. Feb 2014 at 14:17:44 +, Jonathan Moules wrote:
Why not? We're talking about a feature freezed period!? The nightly build
is a snapshot what what will get release. Where do you see a difference?
I think it's a perception thing.
Nightly build in my mind always
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ok, seriously, I should probably emphasize in the freeze announcement,
that it's mainly the users that are supposed to test the daily prereleases
and weekly release candidates and report problems, while the developers
work on reproducing and
Hi,
On Mon, Feb 24, 2014 at 7:41 AM, Filipe Dias filipesd...@gmail.com wrote:
How about making a formal announcement (mailing list, website, wiki etc)
telling
the users that QGIS version 2.X is in feature freeze and therefore is
sufficiently
stable to be tested by end users? This may
Hi Larry,
On Sat, 22. Feb 2014 at 14:33:11 -0700, Larry Shaffer wrote:
How about for a set period of time, only commits that devs think can readily
be ported to the 2.2.0 branch are 'allowed' on master? With any code changes,
which would make porting changes/fixes over to the 2.2.0 branch
On Sun, Feb 23, 2014 at 08:36:07AM +1100, Nyall Dawson wrote:
On 23/02/2014 7:33 am, Larry Shaffer lar...@dakotacarto.com wrote:
How about for a set period of time, only commits that devs think can
readily be ported to the 2.2.0 branch are 'allowed' on master? With any
code changes, which
That reminds me of someone mentioning in a ticket of a 2.0 issue resolved
against qgis 2.1 that he'd wait (angrily?) having fix backported into a
(mythical) 2.0.x update rather than him moving to 2.2 and having to deal
with possible regressions. I was thinking at the time that this sounds to
me
On 24. 02. 14 03:17, Mathieu Pellerin wrote:
QGIS could adopt: 4, or 2, weeks before the release date,
{beta,release candidate,tech preview,etc.} builds (from master, no
need to branch out really) are pushed out to osgeo4w linux and quite
loudly advertised (blog posts, social media, etc.) to
Just to be clear, I don't think QGIS can handle more than one pre release.
The list of terminologies was just there as a pick one name you like :)
On 24 Feb 2014 13:22, Denis Rouzaud denis.rouz...@gmail.com wrote:
On 24. 02. 14 03:17, Mathieu Pellerin wrote:
QGIS could adopt: 4, or 2, weeks
Hi Mathieu,
On Mon, 24. Feb 2014 at 09:17:11 +0700, Mathieu Pellerin wrote:
That reminds me of someone mentioning in a ticket of a 2.0 issue resolved
against qgis 2.1 that he'd wait (angrily?) having fix backported into a
(mythical) 2.0.x update rather than him moving to 2.2 and having to deal
Hi,
I have a suggestion with regards to addressing bugs and supporting the
concept of a 2.2.1 bug-fix release for stability's sake.
How about for a set period of time, only commits that devs think can
readily be ported to the 2.2.0 branch are 'allowed' on master? With any
code changes, which
On 23/02/2014 7:33 am, Larry Shaffer lar...@dakotacarto.com wrote:
How about for a set period of time, only commits that devs think can
readily be ported to the 2.2.0 branch are 'allowed' on master? With any
code changes, which would make porting changes/fixes over to the 2.2.0
branch difficult,
17 matches
Mail list logo
