[GRASS-dev] GRASS 6.3.0 to be released

GRASS GRASS developer
1

(to continue on this thread)

After 6 release candidates, even tested on MS-Windows,
I don't see any real blockers any more. I suggest to get out
6.3.0 this week and proceed with change to 6.4.release_branch/7.0.svn.

We can have 6.3.1 if needed.

Sounds ok?

Markus

On Wed, Mar 19, 2008 at 7:18 AM, Helena Mitasova <hmitaso@unity.ncsu.edu> wrote:

Well given all the troubles reported recently we may as well need RC6 unless
you and Markus have a good sense that these troubles are only in the svn
version and not backported to the release.

I would love to get GRASS6.3 out soon - people are still downloading 6.2 as
the stable GRASS and GRASS6.3 is just so much better. And I need to get some
stable, official release installed in some labs and don't want to use 6.2

thanks a lot, Helena

2

2008/4/15, Markus Neteler <neteler@osgeo.org>:

After 6 release candidates, even tested on MS-Windows,
I don't see any real blockers any more. I suggest to get out
6.3.0 this week and proceed with change to 6.4.release_branch/7.0.svn.

We can have 6.3.1 if needed.

Sounds ok?

+1

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

3

Hi all,

It would be good also for me, even if it would better if we release it on
next week tough (I'm very busy now). BTW, there are few thing to do for me,
just some improvements for windows installer...

Martin, do you think that we could add the needed python files into the
6.3.0 windows package, in order to let users start the pyGUI without the
need to install python stuffs by themselves?

Regards

Marco

-----Messaggio originale-----
Da: grass-dev-bounces@lists.osgeo.org
[mailto:grass-dev-bounces@lists.osgeo.org] Per conto di Martin Landa
Inviato: martedì 15 aprile 2008 19.04
A: Markus Neteler
Cc: GRASS developers list
Oggetto: Re: [GRASS-dev] GRASS 6.3.0 to be released

2008/4/15, Markus Neteler <neteler@osgeo.org>:

After 6 release candidates, even tested on MS-Windows, I don't see
any real blockers any more. I suggest to get out 6.3.0 this week and
proceed with change to 6.4.release_branch/7.0.svn.

We can have 6.3.1 if needed.

Sounds ok?

+1

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

4

Markus Neteler wrote:

(to continue on this thread)

After 6 release candidates, even tested on MS-Windows,
I don't see any real blockers any more. I suggest to get out
6.3.0 this week and proceed with change to 6.4.release_branch/7.0.svn.

We can have 6.3.1 if needed.

Sounds ok?

to me, trac bug #72 is a blocker (PNG driver rendering offset)
  http://trac.osgeo.org/grass/ticket/72

even spearfish fields map looks bad (vertical slivers) when displayed in
the GUI.

As promised, I will work on rewriting the release announcement in the
next day or two.

other lower priority things todo:

http://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&milestone=6.3.0
  http://grass.osgeo.org/wiki/GRASS_6.3_Feature_Plan#6.3.0_final

Hamish

      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

5

On 15/04/08 22:39, Marco Pasetti wrote:

Hi all,

It would be good also for me, even if it would better if we release it on
next week tough (I'm very busy now). BTW, there are few thing to do for me,
just some improvements for windows installer...

Martin, do you think that we could add the needed python files into the
6.3.0 windows package, in order to let users start the pyGUI without the
need to install python stuffs by themselves?

-1

I don't think we should bloat the installer with everything that people might need. It really is not difficult to download and install the python installers...

The only thing we could consider is to add an option to automatically download and install the python stuff, but not add it to our installer directly.

Just my two cents...

Moritz

Regards

Marco

-----Messaggio originale-----
Da: grass-dev-bounces@lists.osgeo.org
[mailto:grass-dev-bounces@lists.osgeo.org] Per conto di Martin Landa
Inviato: martedì 15 aprile 2008 19.04
A: Markus Neteler
Cc: GRASS developers list
Oggetto: Re: [GRASS-dev] GRASS 6.3.0 to be released

2008/4/15, Markus Neteler <neteler@osgeo.org>:

After 6 release candidates, even tested on MS-Windows, I don't see any real blockers any more. I suggest to get out 6.3.0 this week and proceed with change to 6.4.release_branch/7.0.svn.

We can have 6.3.1 if needed.

Sounds ok?

+1

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

6

On Tue, 15 Apr 2008, Markus Neteler wrote:

(to continue on this thread)

After 6 release candidates, even tested on MS-Windows,
I don't see any real blockers any more. I suggest to get out
6.3.0 this week and proceed with change to 6.4.release_branch/7.0.svn.

Yes go for it I say; 6.3.0 is not a stable release and everything does not have to be perfect, but may I suggest that the new branch for continued 6.x development be called develbranch_6 and that a 6.4 release branch be created off there at a future date?

As some parts of GRASS will likely cease to exist in the 7.x HEAD I think it is likely that there will still be some opportunity for development and improvement of backward-compatible things in 6.x for some time to come. E.g. should I end up mentoring a Google Summer of Code student I will certainly recommend that he work in 6.x to avoid extra disruption caused by the 7.x upheaval - and changes can be forward-ported to 7.x later.

Paul

7

Moritz Lennert wrote:

> It would be good also for me, even if it would better if we release it on
> next week tough (I'm very busy now). BTW, there are few thing to do for me,
> just some improvements for windows installer...
>
> Martin, do you think that we could add the needed python files into the
> 6.3.0 windows package, in order to let users start the pyGUI without the
> need to install python stuffs by themselves?

-1

I don't think we should bloat the installer with everything that people
might need. It really is not difficult to download and install the
python installers...

I would suggest two installers: one for GRASS alone, and one for the
various dependencies (PROJ, GDAL, MSys, ...). The idea is that you
shouldn't have to download all of the dependencies each time a new
version of GRASS is released.

An ideal solution would be to use Cygwin's Setup utility, but I don't
know how much work would be involved.

--
Glynn Clements <glynn@gclements.plus.com>

8

Hi Moritz,

It really is not difficult to download and install the
python installers…

yes, I agree… but: when I think to softwares packaging I always keep in my mind all the experiences collected during the years with many users, specially here at my university… specially among teachers and researchers. It’s a consolidated fact, here in my country, that not electronic engineers, specially civil and environmental ones, have a bad relationships with calculators and softwares in general (except with CAD softwares, supposed that they are easy to install…). Since the main target of GIS software is, I guess, exactly this category of professionals (along with geologists)[1], I believe that they would have difficulties, specially on Windows (where users are used to install only self-contained, full-featured packages), to understand exactly what to do; there’s the possibility (note, this is only a personal point of view, but based on direct experience with windows users) that they would not consider to use GRASS because it’s too difficult to install, thus moving to not-opened GIS platforms.

The only thing we could consider is to add an option to automatically
download and install the python stuff, but not add it to our installer
directly.

this would be a very good solution, but I still need to understand how to do that in a clean and tidy manner, 100% working on both XP and Vista (OT: on xext week I’ll probably buy a new PC, with Vista installed, so I’ll can test also on Vista).

Marco

[1] you could not believe that, but here at my university teachers don’t know/use GIS softwares… this said, it’s a main target of my future plans, after the degree on July, to spread the opend GIS (that is GRASS) word here :wink:

Da: Moritz Lennert [mailto:mlennert@club.worldonline.be]
Inviato: mer 16/04/2008 9.29
A: marco.pasetti@alice.it
Cc: ‘Martin Landa’; ‘Markus Neteler’; ‘GRASS developers list’
Oggetto: Re: R: [GRASS-dev] GRASS 6.3.0 to be released

On 15/04/08 22:39, Marco Pasetti wrote:

Hi all,

It would be good also for me, even if it would better if we release it on
next week tough (I’m very busy now). BTW, there are few thing to do for me,
just some improvements for windows installer…

Martin, do you think that we could add the needed python files into the
6.3.0 windows package, in order to let users start the pyGUI without the
need to install python stuffs by themselves?

-1

I don’t think we should bloat the installer with everything that people
might need. It really is not difficult to download and install the
python installers…

The only thing we could consider is to add an option to automatically
download and install the python stuff, but not add it to our installer
directly.

Just my two cents…

Moritz

Regards

Marco

-----Messaggio originale-----
Da: grass-dev-bounces@lists.osgeo.org
[mailto:grass-dev-bounces@lists.osgeo.org] Per conto di Martin Landa
Inviato: martedì 15 aprile 2008 19.04
A: Markus Neteler
Cc: GRASS developers list
Oggetto: Re: [GRASS-dev] GRASS 6.3.0 to be released

2008/4/15, Markus Neteler neteler@osgeo.org:

After 6 release candidates, even tested on MS-Windows, I don’t see
any real blockers any more. I suggest to get out 6.3.0 this week and
proceed with change to 6.4.release_branch/7.0.svn.

We can have 6.3.1 if needed.

Sounds ok?

+1

Martin

–
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

9

Glynn,

I would suggest two installers: one for GRASS alone, and one for the
various dependencies (PROJ, GDAL, MSys, …). The idea is that you
shouldn’t have to download all of the dependencies each time a new
version of GRASS is released.

we could do as follows:

  1. a complete, first time GRASS installer, based on latest release, with all the dependencies built-in
  2. and updater, installed along the first installation, that check the WinGRASS repository looking for last GRASS updates, and download/install only the latest updated files (both for GRASS and dependencies). It would be not an easy work, but I think that I’ll can do it… even if not very soon :slight_smile:

Marco

Da: Glynn Clements [mailto:glynn@gclements.plus.com]
Inviato: mer 16/04/2008 10.20
A: Moritz Lennert
Cc: marco.pasetti@alice.it; ‘Martin Landa’; ‘GRASS developers list’
Oggetto: Re: R: [GRASS-dev] GRASS 6.3.0 to be released

Moritz Lennert wrote:

It would be good also for me, even if it would better if we release it on
next week tough (I’m very busy now). BTW, there are few thing to do for me,
just some improvements for windows installer…

Martin, do you think that we could add the needed python files into the
6.3.0 windows package, in order to let users start the pyGUI without the
need to install python stuffs by themselves?

-1

I don’t think we should bloat the installer with everything that people
might need. It really is not difficult to download and install the
python installers…

I would suggest two installers: one for GRASS alone, and one for the
various dependencies (PROJ, GDAL, MSys, …). The idea is that you
shouldn’t have to download all of the dependencies each time a new
version of GRASS is released.

An ideal solution would be to use Cygwin’s Setup utility, but I don’t
know how much work would be involved.

–
Glynn Clements glynn@gclements.plus.com

10

Marco,

2008/4/16, marco.pasetti@alice.it <marco.pasetti@alice.it>:

> Martin, do you think that we could add the needed python files into the
> 6.3.0 windows package, in order to let users start the pyGUI without the
> need to install python stuffs by themselves?

-1

I don't think we should bloat the installer with everything that people
might need. It really is not difficult to download and install the
python installers...

The only thing we could consider is to add an option to automatically
download and install the python stuff, but not add it to our installer
directly.

I agree here with Moritz. Python/wxPython installation process on
Windows seems to me to be quite simple. I would not expect that the
user how is not able to install e.g. Python will be able to use GRASS
at the end;-)

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

11

Hi,

2008/4/16, Paul Kelly <paul-grass@stjohnspoint.co.uk>:

Yes go for it I say; 6.3.0 is not a stable release and everything does not
have to be perfect, but may I suggest that the new branch for continued 6.x
development be called develbranch_6 and that a 6.4 release branch be created
off there at a future date?

+1

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

12

Hamish wrote:

> After 6 release candidates, even tested on MS-Windows,
> I don't see any real blockers any more. I suggest to get out
> 6.3.0 this week and proceed with change to 6.4.release_branch/7.0.svn.
>
> We can have 6.3.1 if needed.
>
> Sounds ok?

to me, trac bug #72 is a blocker (PNG driver rendering offset)
  http://trac.osgeo.org/grass/ticket/72

That issue has always been there, and isn't easily fixed.

Lines are drawn along the "nearest" axis. E.g. for a line which is
closer to the horizontal than to the vertical, the loop iterates over
the X coordinates, with the Y coordinate determined using Bressenham's
algorithm. The slope is always less than or equal to one, so at each
step the Y coordinate either remains unchanged or increments by one,
according to a test which only uses integer arithmetic.

Polygons are drawn from top to bottom as a single entity (as opposed
to the outline, which is a sequence of individual line segments). For
each row, the X coordinates of the left and right edges are calculated
using floating-point coordinates, then rounded to the nearest integer.
A horizontal line (actually, a one-pixel-high rectangle) is drawn
between the two edge points.

It wouldn't be particularly hard to make the closer-to-vertical case
match, by using the same algorithm in both cases. Making the
closer-to-horizontal case match is harder (and messy).

But ultimately, this is just one aspect of a more fundamental problem:
integer coordinates and odd line widths simply don't mix. You cannot
get this case "right"; you just have to choose which flavour of
"wrong" you prefer.

[X11 largely ducked the issue by stating that single-pixel lines are
implementation dependent. Apart from shielding the X developers from
flak from users who would have preferred a different flavour of
"wrong" (even to the point of insisting that a particular flavour is
actually "the right one"), it allows the use of any line-drawing
functionality which is provided by the video hardware, regardless of
which flavour the hardware uses.]

--
Glynn Clements <glynn@gclements.plus.com>

13

On Wed, Apr 16, 2008 at 6:28 AM, Hamish <hamish_b@yahoo.com> wrote:

Markus Neteler wrote:
> (to continue on this thread)
>
> After 6 release candidates, even tested on MS-Windows,
> I don't see any real blockers any more. I suggest to get out
> 6.3.0 this week and proceed with change to 6.4.release_branch/7.0.svn.
>
> We can have 6.3.1 if needed.
>
> Sounds ok?

to me, trac bug #72 is a blocker (PNG driver rendering offset)
  http://trac.osgeo.org/grass/ticket/72

even spearfish fields map looks bad (vertical slivers) when displayed in
the GUI.

given the answer by Glynn:
  http://lists.osgeo.org/pipermail/grass-dev/2008-April/037267.html
do you want to keep your veto?

I fear that we never go ahead like this.

As promised, I will work on rewriting the release announcement in the
next day or two.

other lower priority things todo:

http://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&milestone=6.3.0

OK, low priority, so we can do it in 6.3.1. It's a *technology preview*, nothing
else what we want to publish now. Bugfree software of this size does not exist.

  http://grass.osgeo.org/wiki/GRASS_6.3_Feature_Plan#6.3.0_final

Can you revise your opinion?

Markus

14

On 16/04/08 10:41, marco.pasetti@alice.it wrote:

Glynn,
  >I would suggest two installers: one for GRASS alone, and one for the
various dependencies (PROJ, GDAL, MSys, ...). The idea is that you
shouldn't have to download all of the dependencies each time a new
version of GRASS is released.
we could do as follows:
1. a *complete*, *first time* GRASS installer, based on latest release, with all the dependencies built-in
2. and *updater*, installed along the *first installation*, that check the WinGRASS repository looking for last GRASS updates, and download/install only the latest updated files (both for GRASS and dependencies). It would be not an easy work, but I think that I'll can do it... even if not very soon :slight_smile:

This actually sounds much more sophisticated than what Glynn proposed. Could you not simply propose one installer with only the latest (complete) GRASS binaries. This installer could check for any existing installation of GRASS and propose to erase that before installing the new version, or install the new version next to the old.

The question then is: do we need a "complete" installer with everything in it (as you suggest), or can we impose the burden of two installers on people, i.e. as Glynn suggests: one GRASS installer + one Dependencies installer. I think this would be the best solution for us, but it would mean that at least for the first installation, users will have to install two packages. If the GRASS installer could test for the installation of the other package and propose to download it and lauch its installation autmagically, then this might be the best solution.

But you're the one doing the work, so the ultimate decision will be yours :wink:

Moritz

15

I would vote for a lean base installer to be distributed on
grass.itc.it. Other projects can build fatter installers based
on that and distribute them. A bare bones installer will be
much easier to maintain for us in the long run.

Benjamin

Moritz Lennert wrote:

On 16/04/08 10:41, marco.pasetti@alice.it wrote:

Glynn,
  >I would suggest two installers: one for GRASS alone, and one for the
various dependencies (PROJ, GDAL, MSys, ...). The idea is that you
shouldn't have to download all of the dependencies each time a new
version of GRASS is released.
we could do as follows:
1. a *complete*, *first time* GRASS installer, based on latest release, with all the dependencies built-in
2. and *updater*, installed along the *first installation*, that check the WinGRASS repository looking for last GRASS updates, and download/install only the latest updated files (both for GRASS and dependencies). It would be not an easy work, but I think that I'll can do it... even if not very soon :slight_smile:

This actually sounds much more sophisticated than what Glynn proposed. Could you not simply propose one installer with only the latest (complete) GRASS binaries. This installer could check for any existing installation of GRASS and propose to erase that before installing the new version, or install the new version next to the old.

The question then is: do we need a "complete" installer with everything in it (as you suggest), or can we impose the burden of two installers on people, i.e. as Glynn suggests: one GRASS installer + one Dependencies installer. I think this would be the best solution for us, but it would mean that at least for the first installation, users will have to install two packages. If the GRASS installer could test for the installation of the other package and propose to download it and lauch its installation autmagically, then this might be the best solution.

But you're the one doing the work, so the ultimate decision will be yours :wink:

Moritz

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Benjamin Ducke
Senior Applications Support and Development Officer

Oxford Archaeological Unit Limited
Janus House
Osney Mead
OX2 0ES
Oxford, U.K.

Tel.: ++44 (0)1865 263 800
benjamin.ducke@oxfordarch.co.uk

------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.

16

Hi Moritz,

This actually sounds much more sophisticated than what Glynn proposed.

yes, it is… but we could make a walkaround… I’ll explain how later…

Could you not simply propose one installer with only the latest
(complete) GRASS binaries. This installer could check for any existing
installation of GRASS and propose to erase that before installing the
new version, or install the new version next to the old.

very good :wink: we are at the same point here. I already thought it some weeks ago, before ro release RC6… and that’s why I already added in RC6 installer some registry key values that would let me the job (that is: let future installers recognise if GRASS is already istalled on the system, what version and where). I already talked with Markus about this option in future WinGRASS installers.

The question then is: do we need a “complete” installer with everything
in it (as you suggest), or can we impose the burden of two installers on
people, i.e. as Glynn suggests: one GRASS installer + one Dependencies
installer. I think this would be the best solution for us, but it would
mean that at least for the first installation, users will have to
install two packages. If the GRASS installer could test for the
installation of the other package and propose to download it and lauch
its installation autmagically, then this might be the best solution.

what do you mean about dependencies? the only dependencies that are indipendent to GRASS binaries is Python!
all the other DLLs are necessary to start GRASS. What would happen if we release GRASS with an additional support (jpeg, for example) not previously supported? we must provide the libjpeg with the installer, or update the dependencies installer?
IMHO, this is a sctrictly UNIX way to think… windows is very different: if you release binaries, you must provide all the DLLs needed by those binaries along with them.
It would be a safer solution to release future WinGRASS installers along with a separated updater: in that way new users would install the whole GRASS package (why provide 2 different installers when users absolutely need to install both GRASS bins and Deps?) or simply download and lunch a smaller updater, that would copy/replace only the new bins and libs.

BTW, I still think that providing separated installers for GRASS and its dependencies is a nonsense…

Best regards,

Marco

Da: Moritz Lennert [mailto:mlennert@club.worldonline.be]
Inviato: mer 16/04/2008 15.07
A: marco.pasetti@alice.it
Cc: Glynn Clements; Martin Landa; GRASS developers list
Oggetto: Re: R: R: [GRASS-dev] GRASS 6.3.0 to be released

On 16/04/08 10:41, marco.pasetti@alice.it wrote:

Glynn,

I would suggest two installers: one for GRASS alone, and one for the
various dependencies (PROJ, GDAL, MSys, …). The idea is that you
shouldn’t have to download all of the dependencies each time a new
version of GRASS is released.
we could do as follows:

  1. a complete, first time GRASS installer, based on latest release,
    with all the dependencies built-in
  2. and updater, installed along the first installation, that check
    the WinGRASS repository looking for last GRASS updates, and
    download/install only the latest updated files (both for GRASS and
    dependencies). It would be not an easy work, but I think that I’ll can
    do it… even if not very soon :slight_smile:

This actually sounds much more sophisticated than what Glynn proposed.
Could you not simply propose one installer with only the latest
(complete) GRASS binaries. This installer could check for any existing
installation of GRASS and propose to erase that before installing the
new version, or install the new version next to the old.

The question then is: do we need a “complete” installer with everything
in it (as you suggest), or can we impose the burden of two installers on
people, i.e. as Glynn suggests: one GRASS installer + one Dependencies
installer. I think this would be the best solution for us, but it would
mean that at least for the first installation, users will have to
install two packages. If the GRASS installer could test for the
installation of the other package and propose to download it and lauch
its installation autmagically, then this might be the best solution.

But you’re the one doing the work, so the ultimate decision will be
yours :wink:

Moritz

17

marco.pasetti@alice.it wrote:

>I would suggest two installers: one for GRASS alone, and one for the
>various dependencies (PROJ, GDAL, MSys, ...). The idea is that you
>shouldn't have to download all of the dependencies each time a new
>version of GRASS is released.

we could do as follows:

1. a *complete*, *first time* GRASS installer, based on latest release,
with all the dependencies built-in
2. and *updater*, installed along the *first installation*, that check
the WinGRASS repository looking for last GRASS updates, and
download/install only the latest updated files (both for GRASS and
dependencies). It would be not an easy work, but I think that I'll can
do it... even if not very soon :slight_smile:

I don't see much point in doing both. If you have #2, it makes #1
rather pointless.

--
Glynn Clements <glynn@gclements.plus.com>

18

Moritz Lennert wrote:

> >I would suggest two installers: one for GRASS alone, and one for the
> various dependencies (PROJ, GDAL, MSys, ...). The idea is that you
> shouldn't have to download all of the dependencies each time a new
> version of GRASS is released.
> we could do as follows:
>
> 1. a *complete*, *first time* GRASS installer, based on latest release,
> with all the dependencies built-in
> 2. and *updater*, installed along the *first installation*, that check
> the WinGRASS repository looking for last GRASS updates, and
> download/install only the latest updated files (both for GRASS and
> dependencies). It would be not an easy work, but I think that I'll can
> do it... even if not very soon :slight_smile:

This actually sounds much more sophisticated than what Glynn proposed.
Could you not simply propose one installer with only the latest
(complete) GRASS binaries. This installer could check for any existing
installation of GRASS and propose to erase that before installing the
new version, or install the new version next to the old.

The question then is: do we need a "complete" installer with everything
in it (as you suggest), or can we impose the burden of two installers on
people, i.e. as Glynn suggests: one GRASS installer + one Dependencies
installer. I think this would be the best solution for us, but it would
mean that at least for the first installation, users will have to
install two packages. If the GRASS installer could test for the
installation of the other package and propose to download it and lauch
its installation autmagically, then this might be the best solution.

I don't think that you even need to go that far. If downloading and
running (in the correct order) two installers is beyond the user's
abilities, chances are that they'll spend a couple of days flooding
the grass-user ML with noob questions before giving up on GRASS
altogether.

--
Glynn Clements <glynn@gclements.plus.com>

19

marco.pasetti@alice.it wrote:

>The question then is: do we need a "complete" installer with everything
>in it (as you suggest), or can we impose the burden of two installers on
>people, i.e. as Glynn suggests: one GRASS installer + one Dependencies
>installer. I think this would be the best solution for us, but it would
>mean that at least for the first installation, users will have to
>install two packages. If the GRASS installer could test for the
>installation of the other package and propose to download it and lauch
>its installation autmagically, then this might be the best solution.

what do you mean about *dependencies*? the only dependencies that
are indipendent to GRASS binaries is Python! all the other DLLs are
necessary to start GRASS.

Yes, but there's no need to re-install those same binaries every time
a new version of GRASS comes out. GRASS (and especially WinGRASS) is a
relatively unstable project. I would expect that several GRASS updates
will be released before any of the dependencies need to be upgraded.

What would happen if we release GRASS with an additional support
(jpeg, for example) not previously supported? we must provide the
libjpeg with the installer, or update the *dependencies installer*?

IMHO, this is a sctrictly UNIX way to think... windows is very
different: if you release binaries, you must provide all the DLLs
needed by those binaries along with them.

And the end result is commonly known as "DLL hell", where every
program tries to install a particular version of common DLLs, often
breaking other programs which rely upon those DLLs.

And whenever a security vulnerability is found in a library, you can't
just replace the library; you have to replace a dozen complete
applications (or, more likely, you just live with having hundreds of
unpatched vulnerabilities).

--
Glynn Clements <glynn@gclements.plus.com>

20

Hi all,

When do you think that 6.3.0 will be released?

Regards,

Marco