Branching - was Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2

[Māris Nartišs]

Hi,

sorry for jumping in, feel free to ignore me.

I had similar confusion about upcoming GRASS releases ant they naming. But 
IMHO now it's too late to change something for 6.1/6.2. We will have to live 
with 6.1.0 soon replaced with 6.2.0.

What is more important - we need to ensure that there will be no such problem 
for 6.3 release (we will have it before 7.0?). 
To bring more clarity about upcoming GRASS releases, Markus has created very 
nice wiki page (http://grass.gdf-hannover.de/wiki/Release_Roadmap). It's good 
to have such things somewhere fixed not just free floating around in list 
archive (especially under different subject's ;) ).

And second - IMHO lot of You (GRASS devs/users) will agree, that we need to 
release more often, as not all users are comfortable with using CVS up 
&& ./configure. "Release when it's ready" is good practice, only it has 
it's 'dark side' - how to know when it IS ready? 
To try to bind GRASS releases to some calendar and feature terms, I proposed 
to try out KDE approach. They have release schedule with dates for all 
release related activities (example: 
http://developer.kde.org/development-versions/kde-3.5-release-plan.html) and 
they have feature plan with (almost) all upcoming release features/bugfixes 
AND developer name who will implement/lead development of listed feature. 
(http://developer.kde.org/development-versions/kde-3.5-features.html)
Every upcoming feature/bugfix has not only it's maintainer, but also it's 
status - TODO, In progress and Finished. 
With such feature list is easy to follow what will be in next release, who's 
working on it and how ready is next release.
Of course, such approach has also it's "dark side" - developers have to inform 
others about they plans and progress, but some of devs like to work in 
isolation only showing something when it's ready. 

If having strict release schedule is too much for GRASS, then having at least 
strict feature plan IMHO could work. Only thing - feature plan is not a 
wishlist - it's more like announcement "For GRASS X.X.X I will do YYYY". It 
should contain only features that CAN be implemented for release XX (in mater 
of timing and required changes) and which WILL somebody implement.
Just to try out such approach for upcoming GRASS 6.3 release, see 
http://grass.gdf-hannover.de/wiki/GRASS_6.3_Feature_Plan

Sorry for mu lang, feel free to add comments or simply ignore this mail.


WBR,
troll Maris.

On Wednesday 09 August 2006 23:03, Glynn Clements wrote:
>
> If 6.1.0 will never have any updates, it would probably be a bad idea
> to build on top of it or use it in an OS distribution. The first
> significant bug would necessitate switching to 6.2, so you may as well
> just skip 6.1 altogether.