Addressing MC stagnation.

Leonard den Ottolander leonard at den.ottolander.nl
Mon May 23 20:21:28 UTC 2005


Hi Jindrich, Miguel,

On Mon, 2005-05-23 at 12:28, Jindrich Novy wrote:
> On Sun, 2005-05-22 at 17:46 -0400, Miguel de Icaza wrote:
> > 	* Release-often: MC has not been officially released for a 
> > 	  long time.  I propose that the current CVS gets released
> > 	  as MC 5.0 and if any issues are found with the release
> > 	  we release 5.0.1, 5.0.2 and so on to address these problems.

I don't see the point of doing a major version jump. Although a lot has
been fixed there hasn't been that much new code introduced to justify
this. 4.6.1 is fine with me. 5.0 would be more of a release number for
when we have full extended charset support and all libraries we depend
upon are up to date.

> Sounds good to me. What about releasing mc in a given time period to
> prevent a lingered release cycle? Releasing a new mc (with changing its
> middle release number for instance) two times per year, say 1st Jan and
> 1st June, would be good at least for the downstream maintainer's point
> of view.

I disagree with this as well ;) . I think the best way to go would be to
work out a road map and work towards the milestones. Although I can
understand why some projects use a periodic release schedule (like
Fedora where it is impossible to synchronize the release of all included
packages anyway) it feels very unnatural for a project like mc. We
should just try to set up the TODO in such a way that we can have a
release once or twice a year (or even more often, but based on a
roadmap, *not* a timetable).

Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research





More information about the mc-devel mailing list