[GRASS-dev] Grass7 tech-preview release [was Re: [GRASS-user] to move or not move ? grass64 <- ? -> 7.0]

Moritz Lennert mlennert at club.worldonline.be
Tue Mar 19 02:25:32 PDT 2013


On 18/03/13 23:04, Markus Neteler wrote:
> On Fri, Jan 11, 2013 at 9:53 AM, Rainer M Krug<r.m.krug at gmail.com>  wrote:
> ...
>> Following the discussion, I would like to install GRASS 7 weekly snapshot. I relized the "Binary"
>> link (http://grass.osgeo.org/download/software/) but it points back to the Linux Download page,
>> but I could not find any binaries there for GRASS 7? Maybe this link should be removed?
>>
>> Just wondering, but not a problem, as I am going to install from source anyway.
>
> In the past days I have cleaned up several of the Web pages.
> I hope they are much clearer now. GRASS 7 downloads are now properly
> mentioned as well.

Much clearer now !

I would like to take this debate as an opportunity to touch upon the 
question of a possible tech-preview release of GRASS7.

Several reasons for that:

- More and more people are using it (and we are pushing more and more 
people toward using it). Binaries are available for windows and mac, but 
not for most Linux distributions. A preview release might make it easier 
for these distributions to package grass7 and make it available to a 
larger audience.

- In many institutions it is (understandably) not easy to convince 
IT-managers to install development snapshots instead of released 
software. Having an official release (even if it is only a tech-preview 
release) should make it easier to install grass7 in institutional settings.

- I think that grass7 is in a form where we can start advertising it 
more widely and more officially. In terms of timing, it would be great 
to be able to get this out before FOSS4G.

- From my own egotistical viewpoint, I would love to be able to use 
grass7 in my classes next school year, and having a release would make 
it much easier for me to do that.

Concretely, I see the following type of procedure to make it possible:

- Freeze the svn repository for any direct new commits for a short 
period (I'd say max 1-2 weeks). Only a few "release managers" should 
still have direct commit access at this point. (Another way to do it 
would be to keep commit rights open to anyone, and the role of the 
release managers would be to control all commits and revert those that 
aren't simple bug fixes during the freeze).

- Publish the state of the code at the beginning of the freeze as RC1 
with a wide call for testing.

- Only bug fix* commits.

- Publish RC2 after some bug fixing (possibly after one week).

- Continue bug fixing*.

- Release tech-preview (possibly at the end of week 2) with a huge 
disclaimer that this is a tech-preview release and not considered final 
and stable.

- Open repository again for more general development.


I don't think we should create a release branch as this would just be a 
tech-preview snaphot of the ongoing development.

This obviously implies that we plan ahead and that all developers know 
when this freeze will happen, thus avoiding to commit any large and 
fundamental changes just before the freeze. And that we all put aside 
time during that freeze for testing and bug fixing.

What do you think ?

Moritz


More information about the grass-dev mailing list