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