Two major releases per year instead of three

Lester Caine lester at lsces.co.uk
Wed Jul 27 10:21:28 UTC 2011


Adrian Buehlmann wrote:
> If we have only two feature releases per year, the releases will most
> likely also be more attractive for users, since they will likely contain
> more new features per release. Which increases motivation to help
> testing pre-releases and motivation to actually*do*  the upgrade.

What pops up in my mind is 'What is left that is missing to require a major 
update?'. Tidying up loose ends on the latest release and clearing any bugs 
needs to go on through the year, and as seems to be the case on many projects 
nowadays, upgrades in many cases simply do not actually add anything for the 
majority of users? I'm still using code that was written 10+ years ago as it 
does the job perfectly.

Of cause Python has already moved the goal posts drastically but is there any 
real incentive to waste time rewriting everything for Python3? Much the same is 
going on in PHP with 'academic improvement' that probably 95% of users will 
never even read about, but breaking 'BC' means everybody has to pander to the 
changes :(

So the real question is 'What is on the road map for the next three major 
updates?' Wouldn't a further segregation be more use so that say the web viewer 
is it's own package that can be developed in isolation tot he core software? 
Although fr that I think I need to start getting a PHP viewer working then I can 
do my own developments.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php



More information about the Mercurial mailing list