Re: [saga-gis-developer] changing parameters
On 06/01/2016 08:28 AM, Johan Van de Wauw wrote:
On Tue, May 31, 2016 at 9:20 PM, Johan Van de Wauw
<johan.vandewauw@gmail.com> wrote:
On Mon, May 30, 2016 at 10:58 AM, Volker Wichmann <wichmann@laserdata.at> wrote:
Hi Johan,
we have never agreed to interpret the version number as in semver, but
you are certainly right that we should do so. SAGA has evolved and is
used in many more use cases as in the past. Actually Olaf and me already
agreed just after the last release (2.2.7) that we should preserve the
last digit for bug fix releases. So the next SAGA version to be released
will be 2.3.0.
I just would like to point out that this will not solve the problem of
maintenance. We are a small team, so we might well end up by never
releasing patch versions unless there will be some help with
back-porting and branch maintenance from others. Would be great if
someone would volunteer for that.
Hi Volker,
I'm a volunteer to do that: designating a few releases as "long term
support" which we can than include in eg debian or QGis.
Hi Johan,
great, thanks for taking this over!
I should add that I believe we should nevertheless still take care
when changing parameters, especially of core modules (eg io_gdal).
This breaks everyone scripts (also saga users, not only those using
saga through qgis).
Yes, in case my previous answer wasn't clear enough on this: we will
take care to keep the parameter interface backwards compatible in minor
releases, backward incompatible changes will result in a new major
version number.
Making the release process somewhat clearer, eg announcing two weeks
before a release that a release will be made, provide at least one rc
version could also involve more people in testing and could perhaps
have avoided some of the 2.2.x releases.
Agreed, we will need to formalize the release process anyway in order to
be able to maintain LTS. Maybe we can work on this off-list and then
come up with a proposal.
It has been proposed before, but I would also recommend switching to
git if we have a LTR branch. Cherry picking commits the main from is
_much_ easier in git than in LTR.
No objections to switch to git, it has several advantages over svn. I
will have a look.
I'm also convinced that it will
probably lead to more contributors if we use github: it makes it easy
to contribute eg documentation updates even if you don't have commit
rights.
I think switching to github is another thing, maybe some day in the
future. Sourceforge also allows to use git, so I suggest to have a look
at this option first and then see how that works out.
Another easy way for new people to contribute could be by writing
tests. This could also have detected problems earlier on.
Since the QGis community is larger, maybe we can have unit tests built
using their framework:
http://www.opengis.ch/2016/02/04/increasing-the-stability-of-processing-algorithms/
If we would switch to github, we could use a platform such as travis
to automate these (or other) tests for every commit (again, not
looking to the core team to set this up).
https://travis-ci.org/
Having tests would be great for sure, but let's go step by step.
Thanks again for taking care and best regards,
Volker
--
http://www.laserdata.at
http://www.alp-s.at/cms/en/
Kind Regards,
Johan
Reply to: