[GRASS-dev] GRASS 6.1.0 release preparation

Markus Neteler neteler at itc.it
Tue Jul 4 09:34:35 EDT 2006


On Tue, Jul 04, 2006 at 03:26:32PM +1200, Hamish wrote:
>Markus wrote:
>
>>Hi developers,
>>
>>I think that the current GRASS 6.1-CVS is in a good condition
>>to be released as GRASS 6.1.0. This will pave the way for
>>GRASS 6.2.0 (stable) which may follow shortly.
>
>horray!
>(outstanding issues for me: fix ps.map vlegend patterns bug and finish
>last i.vpoints details)

Hamish: what's your time line for this?

[... some additions made to announcement from H's comments...]

>>I would suggest to branch off a 6.1.0 branch in CVS to
>>not kill momentum in the HEAD. Important fixes can then
>>be merged if needed. From that branch we get out one or
>>two beta tarballs, then release candidates and finally
>>the 6.1.0 version.
>
>is a full branch really needed? I don't think it is much to declare a
>"freeze" for two weeks and just tag beta1 now, beta2 in 1 week, and
>6.1.0 in two weeks.

I don't like this idea too much for three reasons
- some developer will still commit
- we kill momentum since betas could be delayed
- backporting *important* issues isn't that hard (we did it successfully for 5.4 and 6.0)

Let's keep it decoupled. Keep in mind that it is 6.1.0, not 6.2.0!


> I guess my real question is do we want to provide
>support the 6.1.0 line? If so, a branch is fine, if not I suggest we
>freeze HEAD and use tags.

IMHO, doing that on a tag can become pretty messy.

>>If there are no objections, I'll branch right away.
>>Development continues in HEAD as before and we can
>>extract a first 6.1.0beta for packagers and testers.
>>
>>Further discussion:
>>* The x11-less GRASS can be developed in HEAD, we should
>>  not wait for that. We can have 6.1.1 if desired in near
>>  future. The same applies to the georectifier.
>>
>>* NVIZ/Mac issues we can port from HEAD if they get fixed.
>>  Apparently it's more related to openGL than GRASS.
>>
>>* snprintf(): much discussion, no result. We can backport
>>  once it happens.
>
>all this is fine with me.


I have added G_snprintf() to lib/gis/ and changed all usages of
snprintf() to G_snprintf().
See related
 https://intevation.de/rt/webrt?serial_num=1140&display=History

Paul is working on that now. G_snprintf() submitted to CVS.

Helena mentioned v.in.ascii as show-stopper:
Andrew fixed it, patch applied.

>>An announcement is drafted at
>> http://grass.itc.it/announces/announce_grass610.html
>>The list of changes should be almost up to date, please
>>review and add missing items. Also the wording of the
>>first part could be more press release like.
>
>re. the first part:  (I'm no press release writer, but..)
>
>"A feature release"
>I have no idea what this means vs. a "new release". 5.7.0 was a
>"development preview release" -- do you think that is too scary?

Maybe too scary?


>"is a Geographical Information System (GIS) used for data management,
>image processing, graphics production, spatial modeling, and
>visualization of raster, vector and sites data."
>

changed to
"used for spatial modeling, visualization of raster and vector data, data
management, image processing, and graphics production.
"

>Using "data management" as first point is boring and not to the point of
>GRASS. Rename "sites data"? (keep idea)

sites removed.

>.. ok, reading on I see it needs work .. I'll try to put obvious fixes
>in CVS rather than commenting here.

thanks

>* is the updates section from cvs2cl.pl or from memory? (more eyes needed?)

I used cvs2cl.pl, then selected stuff manually (quite time consuming). Yes,
more eyes needed, but we should reflect only relevant changes which is not
always easy to decide.

>* we should update roadmap.html before final 6.1.0 release.

Sounds good... but we would need to follow that roadmap then which rarely
happened in the past. :)

>>      - GRASS is now ANSI C compliant
>
>is this 100% true?

I dunno - but maybe we are already happy with 95% (rounding error).

>>      - Ported natively to MS-Windows (MinGW based)
>
>maybe change to "Raster and vector engines ported to native MS-Windows
>(MinGW based). GUI access available using QGIS."
>?


You can also use much of winGRASS from "command.com". I didn't
try tcltk since I don't have a modifyable Windows version here.
winGRASS runs also without QGIS. But a bit more text is needed
in the announcement.

Markus




More information about the grass-dev mailing list